On Mon, Jul 28, 2008 at 12:30:23PM -0700, SandeepKsinha wrote: > I am a newbie into these filesystems but I can see the positive sides of > these Alternate Data Streams or multiple data streams too, needless to > mention those. > > If you look a bit more deeper into it, in my perspective and the kind of > implementation I look forward to, here is what I have. You've explained *how* to do it, but not *why* it would be a good idea. I'm aware that it's not that difficult to do. But it becomes a mess for system administrators. Most backup tools won't know how to deal with alternate data streams, so they won't be backed up correctly. rsync, ftp, zip, scp, etc., all don't deal with alternate data streams, so the potential for data loss is limitless. > Access to the multiple data stream can be done through a file descriptor. > Applications can open the multiple data stream to get a file descriptor and > can do read(), write(), mmap().. using the file descriptor. These system > calls would work as if it is been operated on a regular file. > The multiple data streams of a file will be stored in a hidden named data > stream directory inode associated with the file. The hidden directory inode > for the file can be accessed only through the multiple data stream API. Yes, I'm aware that this is how Solaris 9 implemented alternate data streams. For a good time, assuming that /var/tmp/demo_file is a file that contains alternate data forks owned by an unprivileged user, try this command as that unprivileged user: "runat /var/tmp/demo_file chmod 0 ." Now try to get access to the alternate data forks; there is no way to recover without root access. Lovely, eh? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
