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

Christopher Faylor wrote:
On Tue, Nov 17, 2009 at 04:03:14PM +0100, Thomas Wolff wrote:
Christopher Faylor wrote:
On Mon, Nov 16, 2009 at 03:55:43PM +0100, Thomas Wolff wrote:
Thomas Wolff wrote:
Anyway, maybe some syntax could be found that would not be too harmful to become "reserved" for this purpose...
Sorry but I agree with Corinna. On linux/UNIX you can create a file
with a colon in it. We can now do this in Cygwin 1.7 and that's a good
thing. Complicating the path handling to deal specially with colons in
a filename doesn't sound like a good idea to me.
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. There might be stronger objection to implicitly creating a fork with this syntax than to just accessing it, which could be resolved with either a $CYGWIN-configurable option or a mkfork command.

How could we possibly use '/' as a delimiter? Are you really advocating
that we treat every file as a potential directory? So every time
someone says "foo/bar" and "foo" is a file we try to open "foo:bar"?
And what happens when someone says "ls -l foo"? Should that work too?
I'm not really "advocating" it, it's just an idea how it could be handled in case support *is* desired.
And yes, if someone *wants* access to this NTFS feature, why not this way? It's a trade-off - weird (but acceptable) handling for a weird feature.

Whether the default for ls is to show forks or not, might be configurable again. If it does (maybe with -l or -a or -la), it could look like:
... foo
... foo/bar
so it should not pretend a virtual directory structure here.


Problem reports:
Unsubscribe info:

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