I am unable to delete a file from SVN using SharpSvn.
Here is my code:
using (SvnClient client = new SvnClient())
{
// snip...
string filePath = "C:\\path\\to\\file.txt";
client.Delete(filePath, deleteArgs);
}
Here is the exception:
SharpSvn.SvnInvalidNodeKindException: ''C:\path\to\file.txt' is not a working copy'
I confirmed this filepath exists and is tied to SVN. What is the problem?
This question led me to the answer. I was using the incorrect casing in my filepath. Following the example above, maybe I tried to delete the file "C:\path\to\file.txt" but the actual path on disk was "C:\PATH\TO\file.txt". I fixed by using SvnTools.GetTruePath:
client.Delete(SvnTools.GetTruePath(filePath), deleteArgs);
Related
Situation
First of all I must mention that I'm using Solr 8.1.1 and am running the default "solr -e cloud" to do some testing. This is running on a Windows Azure VM. I'm trying to create a PowerShell script that will do some setup on the SolrCloud. The first step in this is uploading a custom Configset. I was using https://lucene.apache.org/solr/guide/8_1/configsets-api.html as guide and the PowerShell command if you take away all the parameters and such boils down to the following:
Invoke-WebRequest -Uri "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=MyConfig" -Method Post -ContentType "application/octet-stream" -InFile "config.zip"
EDIT: For clarity the contents of the ZIP is as follows: https://imgur.com/a/OHR1bf1
Problem
When I run the above command however I'm met with the following error:
Invoke-WebRequest : { "responseHeader":{ "status":500, "QTime":11}, "error":{ "msg":"KeeperErrorCode = NoNode for /configs/MyConfig/lang/contractions_ca.txt", "trace":"org.apache.zookeeper.KeeperException$NoNodeException:
KeeperErrorCode = NoNode for /configs/MyConfig/lang/contractions_ca.txt\r\n\tat org.apache.zookeeper.KeeperException.create(KeeperException.java:114)\r\n\tat
org.apache.zookeeper.KeeperException.create(KeeperException.java:54)\r\n\tat org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:792)\r\n\tat
org.apache.solr.common.cloud.SolrZkClient.lambda$create$7(SolrZkClient.java:415)\r\n\tat org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)\r\n\tat
org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:415)\r\n\tat org.apache.solr.handler.admin.ConfigSetsHandler.createZkNodeIfNotExistsAndSetData(ConfigSetsHandler.java:201)\r\n\tat
org.apache.solr.handler.admin.ConfigSetsHandler.handleConfigUploadRequest(ConfigSetsHandler.java:181)\r\n\tat org.apache.solr.handler.admin.ConfigSetsHandler.handleRequestBody(ConfigSetsHandler.java:111)\r\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\r\n\tat org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:796)\r\n\tat
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:762)\r\n\tat org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:522)\r\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\r\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\r\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\r\n\tat org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\r\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\r\n\tat org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\r\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\r\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\r\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\r\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\r\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\r\n\tat org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\r\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\r\n\tat org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\r\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\r\n\tat org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\r\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\r\n\tat org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\r\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\r\n\tat org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\r\n\tat
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\r\n\tat org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\r\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:502)\r\n\tat org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\r\n\tat org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\r\n\tat
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)\r\n\tat org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)\r\n\tat
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\r\n\tat org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\r\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\r\n\tat org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\r\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)\r\n\tat org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)\r\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)\r\n\tat org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)\r\n\tat java.lang.Thread.run(Thread.java:748)\r\n",
"code":500}}
At line:1 char:1
Observations
When I first "failed" I had created a zip file from my config which contained an additional top level folder (ea instead of MyConfig/solrconfig.xml etc my ZIP was MyConfig/MyConfig/solrconfig.xml) and when I used this the command was run successful but the second command (creating a collection) would fail because it could not find solrconfig.xml. This tells me that the ZIP is correctly present in the request and Solr does seem capable of processing it but once I correct it to an actual configset it massively fails?
EDIT: I was asked about this and whether using "conf" in the zip would work. As I mentioned here this results in a successful upload (https://imgur.com/a/JHLZ8td) however as you can see it does not match the other config sets and when you try to create a collection with this set you will get Error CREATEing SolrCore 'Test_shard1_replica_n1': Unable to create core [Test_shard1_replica_n1] Caused by: Can't find resource 'solrconfig.xml' in classpath or '/configs/Sitecore', cwd=C:\solr-8.1.1\server
Question(s)
What am I doing wrong? Is this a bug?
Going back through some work I did on SolrCloud a while ago, I am reminded of one annoying issue I hit:
I got odd issues uploading the schema config zip files if I had created that zip using "Send to Compressed Folder" in the Windows UI, or via Compress-Archive in PowerShell. I found that compressing the data with 7Zip did work, however.
I suspect there's something incompatible between the Windows zip code (which I think is quite old, and something they licensed ages ago?) and how Solr/ZooKeeper deals with extracting the files again?
I just ran into the same issue without using Windows zip code. I was trying to upload a configset to Solr 7.7.3 from a conf directory containing a "lang" subdirectory with a bunch of files. I got the NoNode error for /configs/_myconfigsetname_/lang/stopwords_eu.txt. The configset was being zipped on the fly through a recursive directory walk in Java, sending each filename to the Zip file using Java's ZipOutputStream. The resulting zipped bytes were then sent to Solr/Zookeeper.
This code worked fine for conf directories without subdirectories. It turned out that when there is a subdirectory, it was necessary to create a ZipEntry for the directory (e.g. lang/) before adding files to the Zip stream such as lang/stopwords_eu.txt.
I am new to cucumber and I am automating a scenario. Initially I kept my features files in the path C:\Users\test\eclipse-workspace\Automation\src\test\resources\featureFile. Then I moved the feature files to a different path (C:\Users\test\eclipse-workspace\Automation\src\test\com\test]automation\features). I have updated the same in CucumberOptions as shown below.
#CucumberOptions(features = {
"src/test/java/com/test/automation/features/CO_Self_Service_Home_Page_Personalizations.feature" }, glue = {
"src/test/java/com/oracle/peoplesoft/HCM/StepDefinitions" })
But when I try to run the feature, I am getting the below exception stating the feature file is not found. Here the path shown in the exception is the old path. I am not sure from where it is fetched as I have updated the new path in Cucumber options. Can you please help me understand the cause of this issue.
Exception in thread "main" java.lang.IllegalArgumentException: Not a
file or directory:
C:\Users\test\eclipse-workspace\Automation\src\test\resources\featureFile\Self_Service_Home_Page_Personalizations.feature
at
cucumber.runtime.io.FileResourceIterator$FileIterator.(FileResourceIterator.java:54)
at
cucumber.runtime.io.FileResourceIterator.(FileResourceIterator.java:20)
at
cucumber.runtime.io.FileResourceIterable.iterator(FileResourceIterable.java:19)
at
cucumber.runtime.model.CucumberFeature.loadFromFeaturePath(CucumberFeature.java:103)
at
cucumber.runtime.model.CucumberFeature.load(CucumberFeature.java:54)
at
cucumber.runtime.model.CucumberFeature.load(CucumberFeature.java:34)
at
cucumber.runtime.RuntimeOptions.cucumberFeatures(RuntimeOptions.java:235)
at cucumber.runtime.Runtime.run(Runtime.java:110) at
cucumber.api.cli.Main.run(Main.java:36) at
cucumber.api.cli.Main.main(Main.java:18)
There are a couple of points you need to take care as follows :
As per Best Practices cerate the directory features which will contain the featurefile(s) strictly through your IDE only (not through other softwares Notepad or Textpad or SubLime3) as per the image below (New -> File) :
Create the featurefile i.e. CO_Self_Service_Home_Page_Personalizations.feature within features directory strictly through your IDE only.
Keep your Project Structure simple by placing the directory containing the featurefile(s) just under Project Workspace. For Featurefiles Cucumber works with directory names. So create the features directory just under your project space Automation (same hierarchy as src). So the location of the Self_Service_Home_Page_Personalizations.feature will be :
C:\Users\test\eclipse-workspace\Automation\features\Self_Service_Home_Page_Personalizations.feature
Again, as in your Class file containing #CucumberOptions you have mentioned glue = {"StepDefinitions" } ensure that the Class file containing #CucumberOptions must be in the similar hierarchy as the figure below :
So your CucumberOptions will be as follows :
#CucumberOptions(features = {"features" }, glue = {"StepDefinitions" })
Execute your Test
Note : Do not move/copy feature file(s)/directory(ies). Delete the unwanted and create a new one through your IDE only.
I’m trying to use waitFor() in my Citrustest to wait for an output file on disk to be written by the process I’m testing. I’ve used this code
outputFile = new File “/esbfiles/blesbt/bl03orders.99160221.14289.xml");
waitFor().file(outputFile).seconds(65L).interval(1000L);
after a few seconds, the file appears in the folder as expected. The user I’m running the test code as has permissions to read the file. The waitFor(), however, ends in a timeout.
09:46:44 09:46:44,818 DEBUG dition.FileCondition| Checking file path '/esbfiles/blesbt/bl03orders.99160221.14289.xml'
09:46:44 09:46:44,818 WARN dition.FileCondition| Failed to access file resource 'class path resource [esbfiles/blesbt/bl03orders.99160221.14289.xml] cannot be resolved to URL because it does not exist'
What could be the problem? Can’t I check for files outside the classpath?
This is actually a bug in Citrus. Citrus is working with the file path instead of the file object and in combination with Spring's PathMatchingResourcePatternResolver this causes Citrus to search for a classpath resource instead of using the absolute file path as external file system resource.
You can fix this by providing the absolute file path instead of the file object like this:
waitFor().file(“file:/esbfiles/blesbt/bl03orders.99160221.14289.xml")
.seconds(65L)
.interval(1000L);
Issue regarding broken file object conversion has been opened: https://github.com/christophd/citrus/issues/303
Thanks for pointing to it!
I need to write a program where I run a set of instructions and create a file in a directory. Once the file is created, when the same code block is run again, it should not run the same set of instructions since it has already been executed before, here the file is used as a guard.
var Directory: String = "Dir1"
var dir: File = new File("Directory");
dir.mkdir();
var FileName: String = Directory + File.separator + "samplefile" + ".log"
val FileObj: File = new File(FileName)
if(!FileObj.exists())
// blahblah
else
{
// set of instructions to create the file
}
When the programs runs initially, the file won't be present, so it should run the set of instructions in else and also create the file, and after the first run, the second run it should exit since the file exists.
The problem is that I do not understand new File, and when the file is created? Should I use file.CreateNewFile? Also, how to write this in functional style using case?
It's important to understand that a java.io.File is not a physical file on the file system, but a representation of a pathname -- per the javadoc: "An abstract representation of file and directory pathnames". So new File(...) has nothing to do with creating an actual file - you are just defining a pathname, which may or may not correspond to an existing file.
To create an empty file, you can use:
val file = new File("filepath/filename")
file.createNewFile();
If running on JRE 7 or higher, you can use the new java.nio.file API:
val path = Paths.get("filepath/filename")
Files.createFile(path)
If you're not happy with the default IO APIs, you an consider a number of alternative. Scala-specific ones that I know of are:
scala-io
rapture.io
Or you can use libraries from the Java world, such as Google Guava or Apache Commons IO.
Edit: One thing I did not consider initially: I understood "creating a file" as "creating an empty file"; but if you intend to write something immediately in the file, you generally don't need to create an empty file first.
How to create new file in a user directory on NetBeans Platform application? I used:
System.getProperty("netbeans.user", "user.home") + "/myfile");
But the NB IDE 7.1.1 told me that it is depreceated and I should use InstalledFile Locator instead. Ok, I tried this:
File file = InstalledFileLocator.getDefault().locate("myfile", null, false);
It works fine, if the file already exists. I cannot see any way, how to create new with the InstalledFileLocator. But the javadoc say, this method allows to get folder. So I tried this:
File file = InstalledFileLocator.getDefault().locate("myfile", null, false);
if (file == null) {
file = new File(InstalledFileLocator.getDefault().locate("", null, false), "myfile");
}
Again without success, the method locate now fails that it can't find anything (the "/" is forbidden and does not work too).
So my question is, how to corectly load in my NetBeans Platform application an existing file in the user directory (it is for writing also, so it should not be in the program directory) and if it does not exist, create it?
You could use Places.getUserDirectory().
File file = InstalledFileLocator.getDefault().locate("myfile", null, false);
if (file == null)
{
file = new File(Places.getUserDirectory() + File. separator + "myfile");
}
From the netbeans platform docs InstalledFileLocator should not be used to find resources on the system filesystem. To find data in the system filesystem, use the Filesystems API. Ex:
FileObject fo = FileUtil.getConfigFile(myfile);
if (fo == null) {
fo = FileUtil.getConfigRoot().createData(myFile,ext);
}
Probably the easiest thing you can do is to include a simple empty file (say "here.txt") in your module that will be installed in the user directory automatically. You can see an example of this here (see the section "Lessons learned: bundling files with your NetBeans modules").
Basically you include the file in the "release/modules/ext/here.txt" directory of your module.
When the module is installed the platform will install the 'here.txt' file included in your module in the user directory automatically for you, so you don't have to worry about this.
Once your module is installed an running you want to locate the file like this:
File hereTXT = InstalledFileLocator.getDefault()
.locate("modules/ext/here.txt",
"a.b.c",
false);
(Where "a.b.c" is your module identifier.)
And then from that 'hereTXT' file you can get the directory with 'hereTXT.getParent()', and you're all set.