This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed


2009/11/17 Eric Blake:
> Thomas Wolff writes:
>
>> Sorry that I take this up once more (after promising <end:of>), but I
>> had this additional idea after seeing your point about being strictly
>> consistent with the POSIX pathname namespace:
>>
>> So what about using "/" as a delimiter? If "foo" is a file, "foo/bar" is
>> not a legal pathname in POSIX, so it could be used to access the "bar"
>> fork of "foo" without causing real harm.
>
> NO - a thousand times no. ÂUsing / in file names, but not as a directory, is
> just ASKING to break everything ever written, and penalize speed of interfaces
> that could care less about this.
>
> But, you _could_ borrow a leaf from Solaris, and support and implementation:
>
> openat(open("foo",flags), "bar", flags)
>
> as a way to open the "bar" stream of the "foo" fd, aka "foo:bar" in windows
> terms. ÂIn other words, open("foo/bar") MUST fail, because foo is not a
> directory, but openat(fd_of_foo,"bar") is an extension allowed by POSIX (just
> because we currently fail with ENOTDIR in that situation doesn't mean we have
> to); and by using the *at interfaces, we could isolate the performance penalty
> to just the situations where the fd is not a directory fd.
>
> You would also want to consider implementing opendir2 (borrowing from BSD
> heritage; there, opendir2 exists to allow the user to select whether whiteout
> entries in a union mount will be ignored), and adding a new DTF_* bit that
> allows opening a file to traverse its alternate streams, instead of the normal
> opening a directory to traverse its contents.

Another example to throw in the mix: OS X. It represents named forks
on HFS+ volumes like this:

<filename>/..namedforks/<fork>

I guess the '..namedforks' bit is there so that
'opendir("<filename>")' can fail as usual, whereas
'opendir("<filename>/..namedforks")' will get at the list of forks in
the file.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]