bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #27146] cp --no-preserve=mode is counter-intuitive


From: Matt McCutchen
Subject: [bug #27146] cp --no-preserve=mode is counter-intuitive
Date: Sat, 13 Feb 2010 22:34:42 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100210 Fedora/3.6.1-1.matt1.fc12 Namoroka/3.6

Follow-up Comment #3, bug #27146 (project coreutils):

On second thought, instead of a new option, I'd like an environment variable
that I could set system-wide and then forget about.  The same environment
variable could be recognized by cp, tar, rsync, and similar programs.  How
about CP_IGNORE_SOURCE_PERMS?  Should POSIXLY_CORRECT override it?

Someone please update the summary appropriately, e.g., to "Option/env. var.
to ignore source permissions when copying".

Re comment #2:
> The problem was (besides that it didn't apply anymore for trivial reasons)
that it set the execute bits on every file. I've made it so that it only sets
the execute bits that were set in the source file but otherwise complies with
the umask.

I don't think that's what we want.  A source file that is executable (has at
least one execute bit set) should be able to gain all unmasked execute bits on
the destination.  For example, if a source file of mode 700 is copied with
umask 022 (or default ACL 755), the destination file should get mode 755, not
744.

> I understand this may not be desirable for some use cases, since the
annoyance is that certain filesystems set the execute bits on every file.
[...] as well as some control over execute bits.

I assume you're thinking of FAT, which doesn't store any permissions except
for a "read only" flag.  You can specify the permissions to use for all
regular files via the "fmask" mount option.  I think it makes more sense to
have all regular files non-executable, rather than executable, so I set
fmask=0177.  But I don't see how this is related to the present issue.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27146>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]