X-Recipient: archive-cygwin@delorie.com
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <loom.20091117T182547-55@post.gmane.org>
References: <26363833.post@talk.nabble.com> 	 <20091116120650.GH29173@calimero.vinschen.de> 	 <4B01462A.3080400@towo.net> 	 <416096c60911160532j2c49cd7ftb79fcc7295f9be21@mail.gmail.com> 	 <20091116135644.GK29173@calimero.vinschen.de> 	 <4B01639C.8000403@towo.net> <4B0167EF.8030807@towo.net> 	 <20091116163415.GD20652@ednor.casa.cgf.cx> <4B02BB32.4090403@towo.net> 	 <loom.20091117T182547-55@post.gmane.org>
Date: Tue, 17 Nov 2009 19:10:49 +0000
Message-ID: <416096c60911171110n53c0ff8dpf24eb158864fee0@mail.gmail.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
From: Andy Koppe <andy.koppe@gmail.com>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com

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. =C2=A0Using / in file names, but not as a direc=
tory, is
> just ASKING to break everything ever written, and penalize speed of inter=
faces
> that could care less about this.
>
> But, you _could_ borrow a leaf from Solaris, and support and implementati=
on:
>
> openat(open("foo",flags), "bar", flags)
>
> as a way to open the "bar" stream of the "foo" fd, aka "foo:bar" in windo=
ws
> terms. =C2=A0In other words, open("foo/bar") MUST fail, because foo is no=
t 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 pe=
nalty
> 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 whit=
eout
> 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 n=
ormal
> 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