Messages in this thread | | | Date | Fri, 11 Aug 2000 15:26:50 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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/
| |