I have this iOS module that creates and writes to some plist files in NSApplicationSupportDirectory, and I'd like to test that the module is performing these writes correctly. However, the writes don't seem to be going through - after calling the module method, the file seems to not exist. I've also tried writing to the desired file directly from the unit test module, and that doesn't seem to do anything either - using NSDictionary writeToFile returns NO, indicating that the write failed.
Is it impossible to write to this directory from a unit test environment, or is it more likely that I just screwed something up? And if it is indeed impossible to perform this write, what would the proper way to test this behavior be? If anyone needs more details, I'd be happy to provide them.
Thanks!
Discovered my own error: The NSApplicationSupportDirectory simply doesn't exist by default (this is why the write is failing). You need to create the directory before you can use it. See this post:
iOS: Can't save file to 'Application Support' folder, but can to 'Documents'
Related
According to this document, Xamarin should be able to write files in personal storage of application. Problem is, I used both XDocument.Save(string path) and XMLWriter to save my XML data to a file, but nothing happens! No Error but the file is not created either.
If you use another path, an exception will be thrown that you don't have access to that space, which means the code tries to write the file, but when you give it a legal space, it doesn't write anything.
I use:
System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal)
to get my path and then add "/file.xml" to it. I give this path to
XDocument doc = new XDocument();
doc = XDocument.Parse("<names></names>");
doc.Save(path);
I tried this solution in windows and it works but not in Xamarin.Android
As for Saving, I was able to do it after giving my app WRITE_EXTERNAL_STORAGE. However it seems odd...since I could write files through File.WriteAllText in the same place...and my code never threw any exception about illegal access or whatever.
After this problem, another odd thing happened. XDocument.Save wrote the file, but later when it wanted to load it, threw exception about "XML Declaration"...the odd part is, XDocument.Save itself writes that part automatically and it can't be wrong!When I checked the file, it was completely OK.
So, I conclude that either XDocument is buggy in Xamarin (since I used the exact code in windows without any problem) or my android device is buggy. Either scenarios are unlikely.
Neither io nor lfs seem to have an option to check for this. I need to use this feature to simulate some code that does this check.
It seems there's an undocumented permissions field in the table returned by lfs.attributes(). Thanks to #siffiejoe for pointing this out, didn't see it when I read the code.
Another approach is of course to try to read from the file, that will always work but might be slower.
You could also try opening the file and setting a (temporary, of course) read lock on it. Not sure about the portability of file locking in Lua, though.
Note: checking if a file is readable and then doing something can break due to race conditions; the permissions of a file can change between your check and the following action.
During part of a request in a Rails application, I copy a directory from one place to another, think of it like a working area. Sometimes this copy operation results in "Errno::ETXTBSY" exceptions being thrown. I can't seem to pin down the case that causes it, any tips to detect the case or avoid it altogether?
I've made sure the destination directory is uniquely named, so it shouldn't be a case of 2 processes attempting to write to the same place. Beyond that I'm out of ideas.
ETXTBSY means that you're trying to open for writing a file which is currently being executed as a program, or that you're trying to execute a file which is currently open for writing. Since you say you're copying files, not executing them it seems likely it's the former, not the later.
You say you're targeting a unique new destination, but my guess is that's not entirely true and you're actually targeting an existing directory and one of the files you're attempting to overwrite is currently open as an executable text segment of a running process.
You haven't posted any code, so it's hard to comment specifically. I suggest you add enough logging so you know exactly what file(s) are being processed and specifically, the source and destination path that throws the exception. Then you could use lsof to see what process may have that file open.
One way to avoid the problem if you are overwriting a currently open executable, is to first unlink the target file. The running process will still have the old inode mapped and proceed merrily using the deleted file, but your open for write will then create a new file which won't conflict.
I am using Progdigy's SevenZip unit to extract RAR files. Works great when RARs are single volume. When I have a multivolume archive then it fails. I am guessing I should add some code to support a callback function which asks for another volume or something, but I am not sure how to do it. Seems it's not supported by SevenZip.pas.
I found something named ArchiveOpenVolumeCallback but no idea how to use it properly. Any help here?
I'm having an issue with Nunit where I cannot find an image file when I run my tests and each time it looks for images it looks in the Nunit folder instead of looking inside the folder where the binary resides. Below is a detailed description of what's happening.
I'm building a binary that is under test which contains the definition for some game elements and png files which will define the sprites I'm using (for sanity sake call it Binary1)
Nunit runs tests from a seperate binary (Binary1Test) executing test methods against the first binary (Binary1).
All tests pass, unless the test executes code in Binary1 which then requires Binary1 to use one of the image files (which are defined via a relative path). When the method is called, Nunit throws a file not found exception stating that it cannot find the file and states it's looking inside of the Program Files\Nunit.net 2.0 folder
So I have no idea why the code is doing this, and to make matters more confusing when I pull up Enviornment.CurrentDirectory it gives me the correct path (the path to my debug folder) and not the path to nunit. Also if I use this instead of using the relative path, my tests will run without issue. So my question is, does anyone know why in the case of loading relative paths from within my binary that nunit decides to use it's directory instead of the directory where the binary is located and where the images are stored? Thanks.
I'm not sure why this is happening, but wanted to mention something that might help you troubleshoot a little. Do you have any Path Constraint assertions in your tests? It might help you troubleshoot this.
Here's the NUnit.org link for the syntax: http://www.nunit.org/index.php/extensions/docs/2.4/files/index.php?p=pathConstraints&r=2.5.1
Here's an example (from the above link) of the syntax for relative paths. You might want to assert that your relative path is the same as an absolute path and see what is going on. At least you'll have a specific failing test about paths that you'll need to get passing.
Assert.That( "/folder1/./junk/../folder2",
Is.SamePath( "/folder1/folder2" ) );
Assert.That( "/folder1/./junk/../folder2/x",
Is.Not.SamePath( "/folder1/folder2" ) );