lkml.org 
[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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