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/
