Re: Patch to allow trailing dots on managed mounts
On Thu, Dec 16, 2004 at 10:04:41PM -0500, Pierre A. Humblet wrote: > * path.cc (path_conv::check): Check the output Win32 path for trailing > spaces and dots, not the input path. Ok. I've convinced myself that doing it what I consider to be the most forgiving way is going to be too expensive, introducing extra code for an unlikely corner case in a routine that is time-sensitive. So, I'm checking in a variation of this patch. It didn't work out of the box and I wanted to add some extra checking so I rewrote part of the patch. For now, I'm disallowing all use of '.\' and ' \' in a path. It seems more consistent to disallow everything than to allow some stuff. I didn't change the symlink code to disallow "ln -s foo bar..." If someone actually complains about this, maybe I will. So, "ls /bin." works, "ls /bin./pwd.exe" doesn't work and "ls /cygwin/c/cygwin/bin./pwd.exe" doesn't work either. Nor does "ls c:\cygwin\bin.\pwd.exe". I don't know if we'll hear complaints about this one or not. >Also, for my info, what is the unc\ in > !strncasematch (this->path + 4, "unc\\", 4))) >around line 868? I have never seen that documented. I've always wondered about that myself. I am pretty sure it predates me. I've removed that test. It doesn't make any sense to me either. Thanks, Pierre. cgf
Re: Patch to allow trailing dots on managed mounts
Christopher Faylor schrieb: On Sat, Dec 18, 2004 at 04:48:50PM -0500, Igor Pechtchanski wrote: There are two possible interpretations here. One is that Reini is proposing to have Cygwin tools always list alternate streams, in which case you're correct, and it's unrelated to the thread. Another is that colons in filenames on certain Cygwin mounts should not represent alternate streams, but should be different files altogether, and thus should be listed normally. That said, I think Reini's wording implies your interpretation, and thus his suggestion should be in a different thread. There really isn't much that we can do with colons, AFAICT. We certainly can't disallow them in the common case and I don't think there is any FindFirstFile/FindNextFile type API which allows us to easily expose them. Although I can see that it would be nice to have a unifying philosophy here I think the strange behavior of a foo:bar on an NTFS file system is not something that we should worry about right now. Agreed. Some different patch for fhandler_disk_file::readdir() on managed mounts later, when the need arises. readdir() performance will be seriously affected, having to look in all regular files for such attached ADS streams. -- Reini Urban
Re: Patch to allow trailing dots on managed mounts
On Sat, Dec 18, 2004 at 04:48:50PM -0500, Igor Pechtchanski wrote: >There are two possible interpretations here. One is that Reini is >proposing to have Cygwin tools always list alternate streams, in which >case you're correct, and it's unrelated to the thread. Another is that >colons in filenames on certain Cygwin mounts should not represent >alternate streams, but should be different files altogether, and thus >should be listed normally. > >That said, I think Reini's wording implies your interpretation, and thus >his suggestion should be in a different thread. There really isn't much that we can do with colons, AFAICT. We certainly can't disallow them in the common case and I don't think there is any FindFirstFile/FindNextFile type API which allows us to easily expose them. Although I can see that it would be nice to have a unifying philosophy here I think the strange behavior of a foo:bar on an NTFS file system is not something that we should worry about right now. cgf
Re: Patch to allow trailing dots on managed mounts
On Sat, Dec 18, 2004 at 04:12:17PM -0500, Igor Pechtchanski wrote: >On Fri, 17 Dec 2004, Christopher Faylor wrote: > >> On Fri, Dec 17, 2004 at 06:01:04PM -0500, Pierre A. Humblet wrote: >> >Christopher Faylor wrote: >> > >> >> While I detest the trailing dot crap, I don't want cygwin to be >> >> inconsistent. I don't want ls /bin./ls.exe to fail but ls >> >> /cygdrive/c/bin./ls.exe to work. >> > >> >Assuming a normal install, the first one is c:\cygwin\bin.\ls.exe, >> >which would NOT fail, while the second is c:\bin.\ls.exe, which would >> >fail as expected (not due to dots). >> >> Ok. Yes. I had a typo. >> >> If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also >> work. Or, both should fail. "consistent" > >If I may chime in, I think there are at least three separate possibilities >for accessing each directory: > >1) via a managed Cygwin mount; >2) via a regular Cygwin mount; >3) via a /cygdrive-prefixed path; and maybe >4) via a Win32 path. > >There's a need for consistency in each of the above cases, but not >between cases. Each may justifiably have different behavior. We >already default to textmode for 4), and 2) and 3) may have different >textmode/binmode behavior. 2 and 3 don't have different textmode/binmode behavior. You use mount to control the behavior. >It could be argued that as you go down this list, the POSIXness >decreases, so it's ok to distinguish trailing dots, e.g., in the first >two cases, and ignore them in the latter two. So, you're saying that 2 should always say "file not found"? Non-managed mounts can't reliably distinguish trailing dots. Unless you want to make every file a symbolic link to the "real" file or always issue an ENOENT when a pathname component has a trailing dot. I don't see a difference between /cygdrive or a mounted drive. Both are cygwin inventions. I don't see a logical explanable reason for what they support to be different. That is another case that I didn't specify. Should /cygdrive./c work? I think I'm coming back to my ENOENT for all trailing dots argument... >Just my $0.02. Using past behavior, which has certainly changed in the last six months and undoubtedly changed a couple of times prior to that, or extrapolating from the behavior of textmode/binmode to justify this is really not an argument that I'm interested in. You can cause cygwin programs to control the behavior of textmode/binmode with appropriate flags to fopen or open or by specifying the explicit use of mount. There is no easy way for a cygwin program to figure out what to do with trailing dots. cgf
Re: Patch to allow trailing dots on managed mounts
On Sat, 18 Dec 2004, Brian Dessent wrote: > Reini Urban wrote: > > > > Thinking some more about this, there are really some inconsistencies with > > > the current and proposed behavior that I don't like. > > > [...] > > I have no strong opinion in these issues (yet), but please look also at > > the related ending-colon ':extension' problem on NTFS. > > Such files are also not listed, but probably should be. > > Why are you hijacking this thread for something unrelated? The > alternate streams are not seperate files, they are just additional file > data. If the need arises then standalone tools should be made to access > them, just like getfacl and friends. They should not be treated as > seperate files because they're not. > > Brian There are two possible interpretations here. One is that Reini is proposing to have Cygwin tools always list alternate streams, in which case you're correct, and it's unrelated to the thread. Another is that colons in filenames on certain Cygwin mounts should not represent alternate streams, but should be different files altogether, and thus should be listed normally. That said, I think Reini's wording implies your interpretation, and thus his suggestion should be in a different thread. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Patch to allow trailing dots on managed mounts
On Fri, 17 Dec 2004, Christopher Faylor wrote: > On Fri, Dec 17, 2004 at 06:01:04PM -0500, Pierre A. Humblet wrote: > >Christopher Faylor wrote: > > > >> While I detest the trailing dot crap, I don't want cygwin to be > >> inconsistent. I don't want ls /bin./ls.exe to fail but ls > >> /cygdrive/c/bin./ls.exe to work. > > > >Assuming a normal install, the first one is c:\cygwin\bin.\ls.exe, > >which would NOT fail, while the second is c:\bin.\ls.exe, which would > >fail as expected (not due to dots). > > Ok. Yes. I had a typo. > > If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also > work. Or, both should fail. "consistent" If I may chime in, I think there are at least three separate possibilities for accessing each directory: 1) via a managed Cygwin mount; 2) via a regular Cygwin mount; 3) via a /cygdrive-prefixed path; and maybe 4) via a Win32 path. There's a need for consistency in each of the above cases, but not between cases. Each may justifiably have different behavior. We already default to textmode for 4), and 2) and 3) may have different textmode/binmode behavior. It could be argued that as you go down this list, the POSIXness decreases, so it's ok to distinguish trailing dots, e.g., in the first two cases, and ignore them in the latter two. Just my $0.02. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Patch to allow trailing dots on managed mounts
Reini Urban wrote: > > Thinking some more about this, there are really some inconsistencies with > > the current and proposed behavior that I don't like. > > [...] > I have no strong opinion in these issues (yet), but please look also at > the related ending-colon ':extension' problem on NTFS. > Such files are also not listed, but probably should be. Why are you hijacking this thread for something unrelated? The alternate streams are not seperate files, they are just additional file data. If the need arises then standalone tools should be made to access them, just like getfacl and friends. They should not be treated as seperate files because they're not. Brian
Re: Patch to allow trailing dots on managed mounts
Christopher Faylor schrieb: On Fri, Dec 17, 2004 at 07:36:15PM -0500, Christopher Faylor wrote: If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also work. Or, both should fail. "consistent" Thinking some more about this, there are really some inconsistencies with the current and proposed behavior that I don't like. Here's a table. Please let me know if I got anything wrong: What Now Pierre's proposal Windows Equiv ls /bin... Works Won't work dir c:\cygwin\bin... doesn't work ls /bin. Works Won't work(?) dir c:\cygwin\bin. works ls /lib/gcc. Works Works(?)dir c:\cygwin\lib\gcc. works ls /lib./gcc. Works Won't work(?) dir c:\cygwin\lib.\gcc. works ls /cygdrive/c/cygwin/bin. Works Works(?)dir c:\cygwin\bin. works ls /bin../ls.exe Won't work Won't work dir c:\cygwin\bin..\ls.exe won't work ls /cygdrive/c/cygwin/bin../ls.exe Won't work Won't work ditto ls /bin/ls.exe... Works Works(?)dir c:\cygwin\bin\ls.exe... works ln -s foo bar. "Works"*Works** .lnk files with dot extensions allowed If I understand this correctly, I think "Pierre's proposal" == "cygwin's behavior before 2004/4", on all counts. So, in thinking about all of this, I have a radical proposal which I have previously alluded to. path_conv::check could detect the existence of trailing dots or spaces in path components of the output win32 path and set ENOENT in such cases unless the file was associated with either a managed mount or Corinna's proposed "posix" mount. The rationale for this is that you really can't (except in the symlink case) create a file with a trailing dot so why should we lie and say that you can? This probably is too radical an idea and would result in breakage. So, my alternate thought is that single dots should be silently ignored in all path components. Multiple dots should be ignored in the trailing path component, regardless of whether the file refers to a directory or not, which makes cygwin slightly incompatible with windows. I'm not sure how spaces fall out in the above table. I'm not sure that the same rules should be applied for spaces and dots above. I have no strong opinion in these issues (yet), but please look also at the related ending-colon ':extension' problem on NTFS. Such files are also not listed, but probably should be. "listing ADS streams" http://cygwin.com/ml/cygwin/2004-11/msg00292.html -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: Patch to allow trailing dots on managed mounts
On Fri, Dec 17, 2004 at 07:36:15PM -0500, Christopher Faylor wrote: >If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also work. >Or, both should fail. "consistent" Thinking some more about this, there are really some inconsistencies with the current and proposed behavior that I don't like. Here's a table. Please let me know if I got anything wrong: What Now Pierre's proposal Windows Equiv ls /bin... Works Won't work dir c:\cygwin\bin... doesn't work ls /bin. Works Won't work(?) dir c:\cygwin\bin. works ls /lib/gcc. Works Works(?)dir c:\cygwin\lib\gcc. works ls /lib./gcc. Works Won't work(?) dir c:\cygwin\lib.\gcc. works ls /cygdrive/c/cygwin/bin. Works Works(?)dir c:\cygwin\bin. works ls /bin../ls.exe Won't work Won't work dir c:\cygwin\bin..\ls.exe won't work ls /cygdrive/c/cygwin/bin../ls.exe Won't work Won't work ditto ls /bin/ls.exe... Works Works(?)dir c:\cygwin\bin\ls.exe... works ln -s foo bar. "Works"*Works** .lnk files with dot extensions allowed If I understand this correctly, I think "Pierre's proposal" == "cygwin's behavior before 2004/4", on all counts. So, in thinking about all of this, I have a radical proposal which I have previously alluded to. path_conv::check could detect the existence of trailing dots or spaces in path components of the output win32 path and set ENOENT in such cases unless the file was associated with either a managed mount or Corinna's proposed "posix" mount. The rationale for this is that you really can't (except in the symlink case) create a file with a trailing dot so why should we lie and say that you can? This probably is too radical an idea and would result in breakage. So, my alternate thought is that single dots should be silently ignored in all path components. Multiple dots should be ignored in the trailing path component, regardless of whether the file refers to a directory or not, which makes cygwin slightly incompatible with windows. I'm not sure how spaces fall out in the above table. I'm not sure that the same rules should be applied for spaces and dots above. cgf *Creates a bar.lnk file which will show up on in a directory listing as just "bar". **Creates a bar..lnk file when using default symlink behavior. Shows up in a listing as "bar." Otherwise behaves as now(?).
Re: Add self to /proc (to support procps 3.2.4)
On Sat, Dec 18, 2004 at 02:10:42PM -, Chris January wrote: >2004-12-18 Chris January <[EMAIL PROTECTED]> > > * fhandler_proc.cc (proc_listing): Add entry for "self". > (proc_fhandlers): Add entry for "self". > * fhandler_process.cc (fhandler_process::fstate): Handle "self". > (fhandler_process::open): Handle "self". Thanks, applied. cgf
Add self to /proc (to support procps 3.2.4)
2004-12-18 Chris January <[EMAIL PROTECTED]> * fhandler_proc.cc (proc_listing): Add entry for "self". (proc_fhandlers): Add entry for "self". * fhandler_process.cc (fhandler_process::fstate): Handle "self". (fhandler_process::open): Handle "self". proc_self.ChangeLog Description: Binary data proc_self.patch Description: Binary data
