X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 18 Nov 2009 12:40:52 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5   	and 1.7 but not mentioned in What's Changed
Message-ID: <20091118114052.GV29173@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20091116120650 DOT GH29173 AT calimero DOT vinschen DOT de>  <4B01462A DOT 3080400 AT towo DOT net>  <416096c60911160532j2c49cd7ftb79fcc7295f9be21 AT mail DOT gmail DOT com>  <20091116135644 DOT GK29173 AT calimero DOT vinschen DOT de>  <4B01639C DOT 8000403 AT towo DOT net>  <4B0167EF DOT 8030807 AT towo DOT net>  <20091116163415 DOT GD20652 AT ednor DOT casa DOT cgf DOT cx>  <4B02BB32 DOT 4090403 AT towo DOT net>  <loom DOT 20091117T182547-55 AT post DOT gmane DOT org>  <416096c60911171110n53c0ff8dpf24eb158864fee0 AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <416096c60911171110n53c0ff8dpf24eb158864fee0@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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