Some time ago (two days or so), when I was happily coding and wanted to save changes, JMP said that it can’t save, because it was modified externally or something like that. I’ve doublechecked and haven’t had those sources opened in any other app, so I’ve tried again with same result. Then I’ve thought “Well, if I close I will lose at worst last few lines of code”. So I closed JMP and discarded changes.
I was wrong. Very, very wrong.
Next time I’ve opened JMP, half of my classes were gone. Literally empty source files. Fortunately I had recent jar and decompiler backup, but still it needs investigating.
I have no idea how to reproduce it though, and won’t even try for safety reasons. Just noting you about the problem.
If the SDK says the files were locked externally then they were locked externally…
Yes, but there wasn’t any other app that were using them running. only JMP. And it still doesn’t explain data loss.
Well it can’t be the SDK editor, it said it couldn’t save anyway ^^ That DataObject is the only reference the IDE has to that file really… And then it says it was changed externally and your data is gone after… There has to be something modifying it. Antivirus? Backup? SVN? idk.
Backups FTW. That’s one reason to use source control and regularly check in even with 1 person projects.
@normen said:There has to be something modifying it. Antivirus? Backup? SVN? idk.
Well, I don't need antivirus as I don't use Windows or other virus-prone OS, like MacOS (my Mac friend had very bad *cough*flashback*cough* about internet slowing down and strange things being sent).
It also isn't backup since my backup script is checking if any java process is running before doing backup (still looking for a way to detect JME only) And somehow I don't think zipping up files (well, 7z-ing them) does modify them and can cause data loss.
Also I do svn commits manually and only when IDE is closed (but for other reasons than data integrity - just don't want to commit changes and then change something in code and have to do it again).
So the problem must be in IDE itself, but I don't know where.
Hm, I have the idea. Maybe IDE is in some rare cases, like mine, double-opening files and lock them from itself? that would explain strange behavior I've seen, though not data loss (unless rogue locked stream tried to save empty file).
@dariuszg-jagielski said:
Well, I don't need antivirus as I don't use Windows or other virus-prone OS,
Then I guess you could have used "man lsof" and actually seen what was holding the files open.
1 Like
@dariuszg-jagielski said:
Hm, I have the idea. Maybe IDE is in some rare cases, like mine, double-opening files and lock them from itself? that would explain strange behavior I've seen, though not data loss (unless rogue locked stream tried to save empty file).
As said, there is only one DataObject for the java file, it isn't written any other way so only if the IDE can actually write the file it could mess it up.