lkml.org 
[lkml]   [2002]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ext3 and undeletion
From
Date
On Wed, 2002-02-27 at 16:40, Alan Cox wrote:
> > Rather than modifying all the different filesystems, or libc, we could
> > modify the VFS unlink function in the kernel. It would therefore work
>
> What about every data loss caused by truncate, overwriting etc..
>
This is a good point. The easiest answer is 'that is what backups are
for'. :-)

More seriously, truncate could be implemented in the truncate calls in
VFS as well, but this would have to be a copy to .undelete rather than a
simple link change. I am not sure implementing truncate in undelete
would be that great of an idea though. Many apps will truncate files
only to update them again, which would result in the .undelete directory
filling the disk. This could be implemented with an optional mount
option and having the default be to not copy truncated files to
.undelete.

Unless I am missing something, overwrite should be handled by the change
to VFS sys_unlink transparently. If a file is overwritten (eg 'cp
/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?

Jamie Strandboge

--
Email: jstrand1@rochester.rr.com
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:20    [W:0.109 / U:30.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site