5 ms·
How could this work? I would expect this method to yield a bunch of matches corresponding to every version of the file that was once saved and continues to live
by a3_nm 12y ago
How could this work? I would expect this method to yield a bunch of matches corresponding to every version of the file that was once saved and continues to live on the disk. Unless you happen to have a string that only existed in the last version or so, but that's hard to come by...
I once did recovery of this kind for a friend (using, I think, photorec or extundelete, not grep) and the hardest part by far was piecing together the "right" version of the files from all matching versions that were recovered from disk.
- danielweber 12y agoI don't think there are any guarantees here, but if he kept on saving the same file with the same name, it probably overwrote the same sector on disk.
- a3_nm 12y agoI guess it depends on the text editor. Some editors will save new versions of a file with the same name by writing the current buffer to a new file and then atomically moving that file to the target location, which has no reason to write on the same sectors.
- rnicholson 12y agoWhat is the reason for saving then moving for existing files? This an optimization specific to certain file systems?
- WalterBright 12y agoSo if there's a write failure the user won't lose his file.
- samdk 12y agoMoving a file (within the same file system) is an atomic operation on most file systems, but writing data is not. If you don't do this and you're overwriting a file directly and the write fails for some reason, the data from the old file will be gone and you'll only have a partially-written new file in its place. This also helps with systems that continuously poll files and watch for changes. If you have, say, a compiler watching your file, you don't want it to start compiling a partially-written version of your file and give you some strange error just because it happened to poll before the write finished.