public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH 0/2] Fix a bad case of absolute path handling
Date: Thu, 11 Nov 2021 10:47:35 +0100	[thread overview]
Message-ID: <YYzmt2ZY5UbhMyHB@calimero.vinschen.de> (raw)
In-Reply-To: <f6a4f67f-1db4-4e53-7907-c7a7dcfbde79@cornell.edu>

On Nov 10 17:22, Ken Brown wrote:
> On 11/10/2021 3:32 PM, corinna-cygwin@cygwin.com wrote:
> > From: Corinna Vinschen <corinna@vinschen.de>
> > 
> > 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

  reply	other threads:[~2021-11-11  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 20:32 corinna-cygwin
2021-11-10 20:32 ` [PATCH 1/2] Cygwin: drop unused isabspath_u and iswabspath macros corinna-cygwin
2021-11-10 20:32 ` [PATCH 2/2] Cygwin: introduce isabspath_strict macro corinna-cygwin
2021-11-10 22:22 ` [PATCH 0/2] Fix a bad case of absolute path handling Ken Brown
2021-11-11  9:47   ` Corinna Vinschen [this message]
2021-11-11 14:10     ` Ken Brown
2021-11-12 16:30   ` Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YYzmt2ZY5UbhMyHB@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).