#3750 I/O error on first save attempt
There is a slight bug in the saving of files, in which when a file is saved the first time after it’s loaded, the following error message is displayed:
>>> The following I/O operation could not be completed:
>>> /Temp/videos:
>>> Cannot save: source path /Temp/videos doesn’t exists
This error occurs regardless if the file is loaded automatically when jEdit is launched or the file is loaded after jEdit is launched.
After this error occurs one time, each subsequent save works fine.
The bug appears to be caused by a combination of settings in the global options dialog. Under the “Saving & Backup” category, if the “Max number of backups” field is cleared to blank (no numbers) and both the “Backup filename prefix” and “Backup filename suffix” fields are also cleared to blank (no characters), then the error occurs.
It appears that when the “Max number of backups” field is blank it’s being interpreted as “1” (or non-zero) and since the prefix and suffix fields are also blank, the backup file name that's generated is the same as the original file name, which is apparently causing some sort of name collision. If the “Max number of backups” field is cleared to blank and either the “Backup filename prefix” or “Backup filename suffix” fields are set to something, then the save succeeds without an error message and a backup file is created. Setting the “Max number of backups” field to “0” solves this bug and prevents backup files from being created.
Recommend that if the “Max number of backups” field is blank it be interpreted as "0" (zero). Also recommend that if the “Max number of backups” field is greater than zero, either the “Backup filename prefix” or “Backup filename suffix” field be forced to something non-blank if both are currently blank. These changes will prevent this error from occurring. Although an easy workaround is to set the “Max number of backups” field to a valid number, the fact that this error can occur suggests the possibility of a file getting corrupted while saving, so the potential for problems ensuing from this bug could be more serious than it appears.
I confirm this bug on trunk jedit version. jEdit gets strongly confused when it is said to backup the file to itself. This seems to be a new bug, as I cannot reproduce on 4.5.0.
On trunk jedit for me steps to reproduce include:
1. clearing backup directory, prefix and suffix
2. setting number of backups to a non-zero number
If I have "backup on every save" on, then I am able to do every second save and every second fails :)
Internal details: makeBackup fails throwing an exception which causes whole save request to fail. I'll think of a solution. I guess preventing bogus backup settings should fix it and be sufficient.
You know, I was looking at the source code and see a curious thing.
In org/gjt/sp/jedit/io/VFS.java, line 599, a call is made to _getFile(). Yet _getFile() at line 875 returns 'null', which would seem to trigger this exception at line 601:
throw new FileNotFoundException("source path " + sourcePath + " doesn't exists");
That is the error message I'm seeing.
Could part of the problem be that _getFile() has not yet been implemented?
Dave
Hi Dave
I already have a patch, but prefer to test it first, as it must also go to 5.0.x branch. The fix is multilevel and I may describe it yet:
1. don't delete the old backup file, if it happens to have the same name as the original file - this is the main source of the problem
2. emit a warning during save, if the backup file turns out to be the same as original file
3. don't stop saving a file, if backup fails
4. emit a warning if a copy of a file to itself is executed, reject this destructive operation
The error is caused by the changes I did to backups recently.
If you want to verify it, I attach the patch. Thanks for your work, Dave. Detecting the error and reporting it before the release of 5.0 branch is very helpful.
And one correction to what I said last time: number of backups > 1 does not trigger the error, as it forces numbered backups and no collision occurs.
patch
Fixed by r22326 for 5.1.
Submitted merge request to fix in 5.0:
https://sourceforge.net/tracker/?func=detail&aid=3575214&group_id=588&atid=1235750