Messages in this thread | | | Date | Sun, 3 Mar 2002 18:17:14 -0800 | From | Mike Fedyk <> | Subject | Re: ext3 and undeletion |
| |
On Wed, Feb 27, 2002 at 10:33:05PM +0000, Alan Cox wrote: > > /root/.bashrc /etc/fstab'), wouldn't 'cp' (or most any other app) first > > unlink the first file (/etc/fstab), then create and write the new one? > > Unlikely - It will truncate it and write over it. Try strace cp 8)
Doesn't truncate use the same inode after the trunc op? If so, then using another inode after the trunc op would break unix semantics. In order to work, you'd have to use a new inode (in .undelete, of course), copy, then do the actual trunc call. This would make truncation expensive, whereas before it was pretty fast. Modifying unlink will probably suffice.
Though, if truncate is modified for undelete, people could claim that our solution is better than others and can save data in more cases. Also, it could be used as a rudamentary file versioning system. :) This feature should be optional, and enabled only at the sysadmin's discression.
Hmm, truncating a large file would basically copy it, and that is what usually happens during a save operation. So, this option needs some serious thinking before proceeding.
Also, it would put more stress on the cleanup facilities of undeletion because more data would pass through the undelete dir. But, communication (however you want do to do that, be it socket or etc...) between the unlink/truncate calls and the cleanup system should make most possible races small or non-existant.
I've probably left something out, so feel free to fill in the blanks.
Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |