Re: [PATCH 0/2] Fix a bad case of absolute path handling
On 2021-11-10 15:22, Ken Brown wrote: On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote: From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. LGTM. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. NO! BTDT GTS. Try getting help from any DOS/cmd type command or subcommand. Shell expands /? to list of all mapped drives /c /d ... /s /v /y which gives you a bunch of potentially destructive switches. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: [PATCH 0/2] Fix a bad case of absolute path handling
On 11/11/2021 4:47 AM, Corinna Vinschen wrote: On Nov 10 17:22, Ken Brown wrote: I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). Yeah, we might try again. Just not over years, we'll probably lose track over time. I'd appreciate a shorter period with a chance to see the end. The problem is that people are probably using DOS paths all the time. Makefiles and scripts mixing Cygwin and DOS tools come to mind. So maybe an RFC email would be useful rather than a HEADS-UP, just to see how widespread it is. For the time being, I wonder if we could start with isabspath being always strict so at least X: isn't an abspath at all. Sounds reasonable. We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. Commented out, you mean? Just as hint? Yes. We could do that. Personally I don't like these shortcuts, I rather use a shorter cygdrive prefix, like /mnt, but I see how this could convince people. Scripts with mixed tools will always be a problem, though. Ken
Re: [PATCH 0/2] Fix a bad case of absolute path handling
On Nov 10 17:22, Ken Brown wrote: > On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote: > > From: Corinna Vinschen > > > > As I told Takashi in PM, I will try to more often send patches to the > > cygwin-patches ML before pushing them, so there's a chance to chime in. > > LGTM. > > > This patch series is supposed to address the `rm -rf' problem reported > > in https://cygwin.com/pipermail/cygwin/2021-November/249837.html > > > > It was always frustrating, having to allow DOS drive letter paths for > > backward compatibility. This here is another case of ambiguity, > > triggered by the `isabspath' macro handling "X:" as absolute path, even > > without the trailing slash or backslash. > > > > Check out the 2nd patch for a more detailed description. > > > > While at it, I wonder if we might have a chance to fix these ambiguities > > in a better way. For instance, consider this: > > > >$ mkdir -p test/c: > >$ cd test > > > > As non-admin: > > > >$ touch c:/foo > >touch: cannot touch 'c:/foo': Permission denied > > > > As admin, even worse: > > > >$ touch c:/foo > >$ ls /cygdrive/c/foo > >foo > > > > As long as we support DOS paths as input, I have a hard time to see how > > to fix this, but maybe we can at least minimize the ambiguity somehow. > > I can't immediately think of anything. But is it really impossible to phase > out DOS path support over a period of time? We could start with a HEADS-UP, > asking for comments, then a deprecation announcement, then something like > the old dosfilewarning option, then a more forceful warning that can't be > turned off, and finally removal of support. This could be done over a > period of several years (not sure how many). Yeah, we might try again. Just not over years, we'll probably lose track over time. I'd appreciate a shorter period with a chance to see the end. The problem is that people are probably using DOS paths all the time. Makefiles and scripts mixing Cygwin and DOS tools come to mind. For the time being, I wonder if we could start with isabspath being always strict so at least X: isn't an abspath at all. > > We could also put lines like > > # C:/ on /c type ntfs (binary,posix=0) > > into the default /etc/fstab. Commented out, you mean? Just as hint? We could do that. Personally I don't like these shortcuts, I rather use a shorter cygdrive prefix, like /mnt, but I see how this could convince people. Scripts with mixed tools will always be a problem, though. Corinna
Re: [PATCH 0/2] Fix a bad case of absolute path handling
On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote: From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. LGTM. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. Ken
[PATCH 0/2] Fix a bad case of absolute path handling
From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. Corinna Corinna Vinschen (2): Cygwin: drop unused isabspath_u and iswabspath macros Cygwin: introduce isabspath_strict macro winsup/cygwin/syscalls.cc | 2 +- winsup/cygwin/winsup.h| 20 2 files changed, 9 insertions(+), 13 deletions(-) -- 2.31.1
