public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Sam Edge <sam.edge@gmx.com>
To: cygwin@cygwin.com
Subject: Re: A notion about saving and restoring Windows file security info
Date: Thu, 6 Jan 2022 09:03:03 +0000	[thread overview]
Message-ID: <7d756609-3681-d150-582a-e9d23765e4b2@gmx.com> (raw)
In-Reply-To: <7cea7819-c03e-60c2-1acc-380b1bd0c18f@cs.umass.edu>

On 05/01/2022 17:41, Eliot Moss wrote:
>  Therefore, my thought is to make the presentation of these
> attributes by attr_list (is that the canonical call?) and probably also the
> special interpretation of them for get/set, controllable in some way.  The
> means of control that occurs to me is an environment variable, or a flag
> within the CYGWIN env var.  Other folks more deeply involved in Cygwin library
> code, etc., may have a more informed notion of the best way to control this,
> but it strikes me as one of those things that you would have to ask for.
>
> In principle, each of Attrs, SDs, and ADS_ could be separately controlled, if
> we think that is important (might be).
>

Hi Eliot.

I can see the appeal of mapping hidden/system/readonly to suitably
namespaced xattrs and exposing ADSes. However I would caution about having too
many selectable options as the behaviour for every combination in the running
system would have to be considered against filesystems that have been
manipulated with every other combination.

As the recent update to setup.exe has shown, even the different types of
symlink handling can cause unforeseen problems and that's a single option with
only a few possible values that only affect how they're written and not how
they're read.

Just a thought.

--
Sam Edge


  reply	other threads:[~2022-01-06  9:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05  3:45 Eliot Moss
2022-01-05 10:34 ` Corinna Vinschen
2022-01-05 17:41   ` Eliot Moss
2022-01-06  9:03     ` Sam Edge [this message]
2022-01-07 13:02     ` Corinna Vinschen
2022-01-07 14:28       ` Eliot Moss
2022-01-07 14:53         ` Corinna Vinschen
2022-01-07 15:40       ` Andrey Repin
2022-01-10  9:59         ` 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=7d756609-3681-d150-582a-e9d23765e4b2@gmx.com \
    --to=sam.edge@gmx.com \
    --cc=cygwin@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).