Mail Archives: cygwin/2005/08/22/10:53:32
On Mon, Aug 22, 2005 at 06:40:54AM -0600, Eric Blake wrote:
>How often does the substring /../ actually appear in path name
>resolution?
You're asking questions and arguing without actually looking at the
source code. It doesn't only matter how often something like this
happens. It also matters how hard it would be to change the current
behavior and what changing it would impact.
Let me state it again: Go ahead and look at the source code and provide
a patch. I'm perfectly willing to have you fix this. Discussions about
what POSIX does or doesn't do are unnecessary. Just provide a patch and
we'll evaluate it on its own merits.
>Another point to consider -
Another point to consider - the current behavior has existed for many years
and the cygwin mailing list is not filled with complaints.
>> and I don't want to remove
>> functionality from 'tar' because the 't' option to fopen() isn't
>> mentioned by POSIX.
>
>This is different - recognizing fopen(name, "rt") is an extension to
>POSIX; nothing in POSIX says you can't have that extension.
To quote from your email from last week:
On Wed, 17 Aug 2005 16:47:19 +0000, Eric Blake wrote:
>But opening with "rt" is non-POSIX, while opening with "r" or "rb" is
>POSIX, so the upstream maintainers are more reluctant to accept a patch
>that uses "rt". I have never seen any standards documentation that
>describes what "rt" should do, so I assumed that it forced opening a
>file in text mode (ie. all \r\n in the file are collapsed to n to the
>application reading the file, regardless of the mount point f the
>file). It sounds like you are telling me my assumption was rong, and
>that "rt" on a binary mount point preserves \r?"
I find those types of discussions very tedious and unproductive. I am
not interested in hearing what POSIX does or doesn't provide when we're
talking about things that Cygwin needs to do to operate reasonably.
>>And, although I use SUSv3 as a reference, when I'm looking for
>>compatibility, I really only care about how things work on linux. If
>>there is a conflict between POSIX and linux, then linux wins, unless
>>there is a really compelling case otherwise. Luckily, usually linux
>>and SUSv3 agree.
>
>I have personally encountered several places where Linux and SUSv3
>disagree;
Did you happen to notice my use of the adverb "usually" above?
>But Linux DOES correctly dereference '/../' in path names passed to the
>kernel.
You know, I had a line in my original email which said "Yes, I know that
Linux does, of course, do the right thing with /../" but I thought it
sounded too mean and that since I'd given all of the reasons for not
wanting to personally tackle changing this behavior, no one would be
tempted to make this obvious point. Next time, I guess I'll know
better.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -