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] Cygwin: Add /dev/disk/by-label and /dev/disk/by-uuid symlinks
Date: Tue, 21 Nov 2023 16:24:12 +0100	[thread overview]
Message-ID: <ZVzLnADL0i2X3orL@calimero.vinschen.de> (raw)
In-Reply-To: <0ba1c78e-15e6-65a2-eb4d-16ac2495c356@t-online.de>

Hi Christian,

Looks good, but I just realized that I was already wondering about the
sanitization and forgot to talk about it:

On Nov 21 12:24, Christian Franke wrote:
> diff --git a/winsup/cygwin/fhandler/dev_disk.cc b/winsup/cygwin/fhandler/dev_disk.cc
> index c5d72816f..d12ac52fa 100644
> --- a/winsup/cygwin/fhandler/dev_disk.cc
> +++ b/winsup/cygwin/fhandler/dev_disk.cc
> @@ -64,10 +64,12 @@ sanitize_label_string (WCHAR *s)
>    /* Linux does not skip leading spaces. */
>    return sanitize_string (s, L'\0', L' ', L'_', [] (WCHAR c) -> bool
>      {
> -      /* Labels may contain characters not allowed in filenames.
> -	 Linux replaces spaces with \x20 which is not an option here. */
> +      /* Labels may contain characters not allowed in filenames.  Also

Apart from slash and backslash, we don't have this problem in Cygwin,
usually.  Even control characters are no problem.  All chars not allowed
in filenames are just transposed into the Unicode private use area, as
per strfuncs.cc, line 20ff on the way to storage, and back when reading
the names from storage.  This, and especially in a virtual filesystem
like /proc, there's no reason to avoid these characters.

> +         replace '#' to avoid that duplicate markers introduce new
> +	 duplicates.  Linux replaces spaces with \x20 which is not an
> +	 option here. */
>        return !((0 <= c && c <= L' ') || c == L':' || c == L'/' || c == L'\\'
> -	      || c == L'"');
> +	      || c == L'#' || c == L'"');

If you really want to avoid chars not allowed in DOS filenames, the
list seems incomplete, missing '<', '>', '?', '*', '|'.

But as I said, there's really no reason for that.  I simply reduced the
above expression to

  return !(c == L'/' || c == L'\\' || c == L'#');

and created a disk label

  test"foo*bar?baz:"

It works nicely, including stuff like

  $ ls *\"*
  $ ls *\**

So, I can push it as is, or we just allow everything and the kitchen sink
as per the reduced filter expression.  What do you prefer?


Thanks,
Corinna

  reply	other threads:[~2023-11-21 15:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 14:39 Christian Franke
2023-11-17 16:23 ` Corinna Vinschen
2023-11-17 16:45   ` Christian Franke
2023-11-17 16:49     ` Corinna Vinschen
2023-11-17 17:53       ` Christian Franke
2023-11-17 19:40         ` Corinna Vinschen
2023-11-17 20:25           ` Christian Franke
2023-11-20  9:40             ` Corinna Vinschen
2023-11-20  9:46               ` Corinna Vinschen
2023-11-20 14:54                 ` Christian Franke
2023-11-20 20:02                   ` Corinna Vinschen
2023-11-21 11:24                   ` Christian Franke
2023-11-21 15:24                     ` Corinna Vinschen [this message]
2023-11-21 18:31                       ` Christian Franke
2023-11-21 18:41                         ` Corinna Vinschen
2023-11-22  9:18                           ` Corinna Vinschen
2023-11-22 16:31                             ` Christian Franke
2023-11-23 16:27                               ` Corinna Vinschen

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=ZVzLnADL0i2X3orL@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).