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


On Nov 17 19:10, Andy Koppe wrote:
> 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.
> > [...]
> > 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.

Both implementations would be fine since they allow to encapsulate this
special behaviour so that it only kicks in if it's explicitely
requested.  But it's certainly nothing for 1.7.1, and personally I do
not exactly care for streams, so don't count on me to implement it.

Anyway, *if* somebody wants to do that, I'd like to point to the
NtQueryInformationFile function with the FileStreamInformation info
class.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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