Hello, I have come across the following behavior that occured before and just recently occured. I have experienced this multiple times now and I am sure it is deterministic behavior.
1. Please specify if this issue has been resolved and the bug report thread where it is resolved to its completion as #2 and #3, the corruption of data files viewed by Idea, is catastrophic. (in the sense that the possibility of this happening, which apparently exists, leads to the complete seizure of Idea's use)
2. Please specify that Idea's architecture of keeping file handles open has been fundamentally changed to remove the possibility of catastrophic data corruption occuring. It is catastrophic to have the possibility of data corruption despite whatever conveniences and performance offered by file handles that allow this occur.
The following bug reports allude to this prevelant and catastrophic corruption but do not appear to be reasonably addressed or resolved:
I have created a bug report as the details I am providing are the most specific and detail the issue in its multiple manifestations: http://youtrack.jetbrains.com/issue/IDEA-110311
After blue screen crashes I have encountered the following 3 types of file corruptions. I believe they all stem from the same architecture as they all presumably generally revolve around the contents of workspace.xml being corrupted in various fashions:
1. Workspace.xml corruption. This is the most common corruption after the blue screen I experience. I have uploaded a zip with some of the corrupted workspaces. The following 3 types of corruption can be seen:
- It appears that the workspace.xml does not have apparent corruption (with the nulls and opened file being written into the it) yet Idea is not able to open the workspace file. After placing such a workspace in the recycle bin and then restoring it, the corruption is visible. This type of workspace.xml corruption appears to be most common. Viewable in workspace.xmlc3
- The contents of an opened file in Idea are written into the workspace followed by a bunch of bytes and the continuations of the workspace xml. Viewable in workspace.xmlc and workspace.xmlc2
- The contents of the workspace.xml are removed entirely leaving a 0 size file
2. Portions of some Idea's xml configuration data is written to I think, the file that was being viewed in the Idea at the time of the crash. However it is possible that multiple files are overwritten in this fashion.
3. I encountered a different type of data corruption at the same as #2 happened recently. A file was somehow corrupted in the following way:
When attempting to git this file (I believe on git add -u though it may have been on commit), git specified that a "short file" was encountered and my gitall bash script failed. Unfortunetly I did not save the the exact error and what occured because I was super excited for locating the exact problem as my compiler was erroring with an indescript error.
The file when fed to the haxe compiler (ocaml) errored with a sys_error("Invalid argument"). Such an error I have encountered previously with #1 (with the file data clearly corrupted/xmled)
The file was temporarily viewable and it's contents were valid. However, the contents of the file sponataneously changed to blank as viewable in notepad++ and the file was removed from Idea's project view hieararchy. After restarting the computer, opening the file with Notepad++ displayed an empty file, however it's size was not 0. Attempting to save the file with Notepad++ specified that the file could not be saved because another program was interfering (this was not the case).
Placing the file in the recycle bin and restoring it, made data corruption became visible as viewable in Notepad++. The file is included as Object_validate_i_v.hx
These visible symptoms perhaps make more sense:
1. With a hex or byte editor
2. Knowledge of what occurs on an ntfs file system at crash
3. Knowledge of how opened file handles work and Idea's architecture with regards to that