I have a piece of simple code residing in a method that gets called thousands of times during an analysis. Most of the time it works fine, but every so often it produces an fileIO exception error 104. The error occurs in a different analysis each time, but always at the same line of code. Here is the code:
outfile = outputFolder.child("micascript.sh")
outfile = outputFolder.child("micascript.sh")
dim outstream as textOutputStream = TextOutputStream.create(outfile)
The error is always at the third line. When I check outfile (in the debugger) it always shows the correct path to the file being created, and outfile is a valid folderitem (it is not nil and it has appropriate pathnames, etc).
The error at the third line shows that outstream = nil (makes sense before this line is executed) and outfile is valid.
My analyses iterate this process thousands of times. It basically writes a text file that is used as a script. The script is executed and the process is repeated. I use the same name for the script file (micascript.sh), so the file will get overwritten each time if it exists. I have tried to check for the existence of micascript.sh and if it exists, I delete it (before creating it again), but that does not help.
There is something that seems to be random here. Any ideas on how to pin this down?
I’m using Mac 10.8.5 and Xojo 2013r4.1. Can reproduce this on three different computers.
Did you forget to close a previous textOutputStream or textInputStream with that file? Make sure to close the streams when you’re done using them and before creating another stream with the same file, as there’s a chance that leaving them open will cause the file to unreadable/unwritable.
When you’re calling the piece of code thousands of times, is it for the same file? Or for thousands of different files once? If it’s all for the sample file it might make sense to leave it open instead of opening/closing it that much.
The file name stays the same, but the executable is different within the file. I have to provide values to the command line routine, and that is what changes each time. The same file (micascript.sh) gets executed over and over again, but the contents of the file change each iteration.
That certainly could be. I’m not sure how to check that, though. I DID try to reboot in Safe mode and run the analysis with the same result, so if there is something else going on behind the scenes it is still happening in Safe mode.
I’d use something like GetTemporaryFolderItem
Wont be duplicated, will be in the users “temporary files” location so it gets cleaned up by normal processes & you won’t have to worry about getting the same file used over & over & having this issue
Hmmm… Let me give that a try. The script must execute in a specific folder but it uses full pathnames as input, so I should still be able to specify the specific path even to a temporary folder, right?
GetTemporaryFolderItem uses the system’s Temporary folder so that won’t be at your specified directory. You could just make a file with a random file name within your desired directory to ensure it’s a new file each time, but then you’ll have to clean it up yourself.
Son once I write the file, I then have to execute it. Having the same name each time makes it easy to do that. If I generate a temporary file, will I be able to get its exact pathname? The script also generates an output file in the same directory as the script file. I then need to read results from than output file. Is this all doable with a temporary directory?
This still doesn’t address the problem of what is wrong with the code I am running.
[quote=61748:@Robert Gross]Son once I write the file, I then have to execute it. Having the same name each time makes it easy to do that. If I generate a temporary file, will I be able to get its exact pathname? The script also generates an output file in the same directory as the script file. I then need to read results from than output file. Is this all doable with a temporary directory?
[/quote]
Sure
folderitem.nativepath is one thing to look at
and the output can be put where ever you want with a proper path name as well
Deleting a file may / may not be instantaneous for any one of a number of reasons
Spotlight has been known to cause problems like this. But in any case, have you tried waiting a fraction of a second and trying again? The file will eventually be released and deleted.
Using the same name maybe exactly what creates the problem. If for some reason the system was not finished deleting it, then trying to create the same file again would collide and create the error.
Tim’s suggestion did the trick (Thanks!). Once I found that alternating file names worked, it made some sense (in retrospect). I have been working on this project about 6 months and just recently started having this problem. In thinking about it, the problem started at about the same time that I implemented a 10x increase in speed - thus the system had 1/10th the time to delete files and obviously had some problems with it. In addition, I noticed that the problem occurred more frequently on my (old) laptop than on my office desktop computer. Perhaps the newer desktop computer could delete files quickly enough to not run into problems, but my laptop is too slow.
Thank you all for your feedback. As usual, the Xojo forum has proven to be invaluable!