So it doesn't even remove the old data the data is preserved in a backup file. If vi is actually vim, the :x command does the following: unlink("existing_file~") = -1 ENOENT (No such file or directory) rename("existing_file", "existing_file~") = 0 open("existing_file", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3
#Open old mac text file in linux free
And as above, they will generally be added to a free list, and may or may not get reused by the subsequent writes done by the cp command. The O_TRUNC flag will cause all the data blocks to be freed, just like mv did above.
This is why the standard advice to people who accidentally remove a file is to not write any new data to files in their directory tree (and preferably not to the entire filesystem) until someone can attempt file recovery.Ĭp new_file old_file will do the following (you can use strace to see the system calls): open("old_file", O_WRONLY|O_TRUNC) = 4 So there's a chance that unlinking a file from a directory and creating a file in that same directory will re-use (and overwrite) some of the same blocks that were just freed. On filesystems like UFS, blocks are allocated, if possible, from the same cylinder group as the directory the file was created in. These newly-allocated blocks may or may not be the same ones that were just freed. Then, if the mv requires copying (a opposed to just moving directory entries), new blocks will be allocated as mv writes. Otherwise, the blocks will generally (it depends on the filesystem type) be placed on a free list. If there are additional hard links to old_file, the blocks will remain unchanged in those remaining links. None of those three examples will overwrite the physical data blocks of old_file or existing_file, except by chance. The answer is "Probably yes, but it depends on the filesystem type, and timing."
0 kommentar(er)
