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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:31 EST