lkml.org 
[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NTFS-like streams?



On Fri, 11 Aug 2000, Jeff V. Merkey wrote:

> i.e. The NTFS method is filename:attribute_name. This means folks just
> append :attr_name to the filename to tell the underlying FS to open an
> alernate attribute file. In this way, this method could be implemented
> across all the FS's in Linux. The question is whether utils check for
> the ':' character in the name stream. You need to expose this lower
> down since NTFS will store them as attributes, but other FS's could
> store them as alternate files, much the same as is done with HFS and
> Macintosh resource forks and finderinfo today in Linux.

If you want to see some seriously scary code - look at the HFS
handling of that stuff. And no, I would not bet a dime that it's done
correctly. The main problem is that rename(), unlink(), etc. are too
fine-grained for such beasts. It's not that filesutils will barf on names.
Just suppose that you are saying mv * foo/bar. Shell will substitute
the whole whorehouse - filename1:attribute1, filename1:attribute2, etc.
and in the best case mv will call rename() on each of them (just how should
we interpret "move the attribute A of file B into directory foo/bar"?).
In the worst it will try to _copy_ them and then remove the old ones.
Moreover, you are going to confuse the hell of VFS and every program out
there (let alone POSIX, etc.) if rename() on one name will move a bunch of
other. It just does not happen.

Doing that will mean (modulo internal kernel problems) complete QA
on every program that has a chance to run on such filesystem. From scratch.

The first problem will be to map the things you've got there on the
semantics expected by userland. And choice of the names is the least of your
problems (if you find anything that doesn't deal with ':' in names - report
it as a bug, it's a valid symbol for any UNIX filesystem and programs _must_
be able to deal with it).

Kernel part really depends on such mapping, so IMO thinking about
that part is a waste of time until the userland issues are really
well-understood.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.064 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site