Hi Andreas,
> Mike Harris writes:
> > As of ext2 fs 0.5a, the `c' and `u' attribute are not hon
> > oured by the kernel code. As of the Linux 2.0 kernel, the
> > 'A' attribute is not yet supported by the kernel code.
> > (The noatime code is still in testing.)
> >
> > Well, as for "c", I know e2compr adds that support, however has
> > anyone ever done patches for "u" support (undelete flag)?
>
> There were a couple of patches for ext2 undelete, but in the end people
> decided that it is possible to implement undelete in libc, so it was
> better not to put this into the kernel. Whether code currently exists
> to do this for a recent kernel, I'm not sure. As for e2compr, I think
> code is slowly making its way into the mainstream - e2fsprogs is now
> starting to have support for it...
If it works, then you can just take a huge textfile and it will be
compressed immediately if you put the c flag on it? Or do you have to
read/write it afterwards, or do you even have to start with a touch
file?
> > We now have "noatime" and "nodiratime" options in kernel. Is the
> > "A" flag supported now at all?
>
> Yes, it allows noatime to be set on an individual file basis, while
> the noatime flag is for the whole filesystem.
What does nodiratime do exactly? A quick grep on the kernel source
didn't educate me, and man mount only mentions noatime.
> > Does the "s" secure delete flag do anything, or is it just a
> > placeholder as well?
>
> Not currently working. There is a comment in the kernel code that shows
> it existed at one time, but was removed because it made the truncate
> code much more complex. Maybe it is possible to put back into the
> ext2_delete_inode() function or similar VFS callback that is guaranteed
> to be the sole owner of the file? I don't know - I haven't looked at it
> closely.
>
> Note that _real_ secure file deletion is much more difficult than simply
> writing 0's then 1's over the data (as much as the US Government would
> like you to believe this). I read a paper that suggested 27 passes of
> specific byte codes + random data were necessary to even have a hope of
> having the data be securely deleted.
Hmm, do you have an url about this? How is it possible that data is
still on disk if you write 0's and 1's over them? (or am I missing
something?).
Thanx!
Ookhoi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST