Messages in this thread | | | Date | Mon, 14 Aug 2000 13:54:09 -0400 (EDT) | From | Rob Newberry <> | Subject | Re: NTFS-list streams? |
| |
I hope I'm not bringing up points that have already been made a bunch of times already. I typically only lurk around this list, but as a longtime Mac/Linux and NT/Linux person, I'm particularly interested in this discussion. I'm also the lead engineer on an Macintosh file server for NT systems, so I've thought about some of these issues a bit -- the lack of support for multi-forked files is one of the reasons I'm not eager to port my application to Linux. Letting the file system do that part of the work is, well, simpler :-).
Anyway, if I understand correctly, the proposed approach is to have HFS/HFS+ resource forks show up as "filename/resource". I don't see any _particular_ problem with this approach on HFS. And for the present time, it works with HFS+. However, NTFS can create a problem with this approach because stream names are abitrary. (For the record, HFS+ by design supports multiple, arbitrarily named streams as well, but the Mac doesn't expose support for them), and because, under NTFS (and by design, HFS+), a directory can also have multiple named streams.
Suppose I have a directory called "dir" and it has a stream called "resource" and it also has a file in that directory called "resource". How do I specify which to use?
As people know, Win32/NT use a special delimiter for this type of thing. Using this convention, "dir/resource" gets me the file in the directory, while "dir:resource" gets me the secondary stream of the directory itself.
I _PERSONALLY_ would prefer an extended "open" call or new API. I'm from a Mac/NT background, and I know that introducing a Linux-only API/system call might not be what people want. But I will say that I find it very useful and much more clear about what the underlying functionality does. This extended open call takes the path to the file, and an optional parameter as the name of the stream. Since most file systems simply won't support this, they will always fail this call. But file systems like NTFS and HFS/HFS+ will work just fine.
I'm going to go back to lurking, but I didn't think I'd seen an answer to this problem yet.
Cheers,
Rob
--------------------------------------------------------------------- Rob Newberry Director of Fajita Technology Group Logic, Inc.
- 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/
| |