bugGNU Core Utilities - Bugs: bug #27146, cp --no-preserve=mode is...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  None
Submitted:  Thu 30 Jul 2009 11:57:13 PM UTC
Votes: 70
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Sun 13 Jan 2013 10:42:38 PM UTC, comment #4: 
Pádraig Brady <pixelbeat>
Group administrator
Sat 13 Feb 2010 10:34:42 PM UTC, comment #3: 

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.

Matt McCutchen <hashproduct>
Mon 01 Feb 2010 04:10:59 AM UTC, comment #2: 

I've modified cp on my system based on a patch found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488024

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 understand this may not be desirable for some use cases, since the annoyance is that certain filesystems set the execute bits on every file. I also understand that the coreutils devs are never going to make the --no-preserve=mode option do something reasonable due to POSIX. I would suggest adding a new option in order to provide this behavior, as well as some control over execute bits.

(file #19587)

Mark Tiefenbruck <markt>
Sat 28 Nov 2009 03:28:05 AM UTC, comment #1: 

I agree with this argument that --no-preserve=mode is merely the opposite of --preserve=mode and should not activate completely new behavior.

Regarding the default behavior of cp, I agree heartily that the current, historical behavior is nearly useless and simply applying the destination default permissions (umask or default ACL) would be much better.  Nevertheless, the historical behavior has stood for a long time and been adopted by tar and rsync, and while I personally would be happy to change the behavior of all of those tools on my system and see what breaks, I highly doubt the maintainers would want to do that to everyone.  sigh  So instead, let's seek a new option to use the destination default permissions and ignore the source permissions.

This issue is quite dear to me.  I originally raised it on the bug-tar list in 2005.  Ultimately, it drove me completely away from GNU cp in favor of rsync, where I popularized the --chmod=ugo=rwX combination (see this commit to the man page) and implemented support for default ACLs to go along with it.

Matt McCutchen <hashproduct>
Thu 30 Jul 2009 11:57:13 PM UTC, original submission:  

Currently cp option --no-preserve=mode behavior is counter-intuitive.  What one would expect is that --no-preserve=mode should set mode to (0666 & ~umask).  See below for a shell transcript (coreutils 7.4).

$ umask 0002
$ mkdir 1
$ cd 1
$ touch file1
$ ls -l
total 0
-rw-rw-r-- 1 grib grib 0 Jul 19 21:48 file1
$ touch ../file2
$ chmod 0644 ../file2
$ ls -l ../file2
-rw-r--r-- 1 grib grib 0 Jul 19 21:48 ../file2
$ cp ../file2 .
$ cp --no-preserve=all ../file2 ./file2-no-preserve-all
$ ls -l
total 0
-rw-rw-r-- 1 grib grib 0 Jul 19 21:48 file1
-rw-r--r-- 1 grib grib 0 Jul 19 21:50 file2
-rw-r--r-- 1 grib grib 0 Jul 19 21:50 file2-no-preserve-all

There is a usecase for behavior I'm requesting (but I can't think of a usecase for current behavior).  For example, a shared directory on a multiuser computer could set-group-id and owned by group users.  If appropriate umask value (0002) is used, then all new files created in the shared directory would be owned by group users and group-writable.  All new directories would be set-group-id.  But files copied (with cp) to the shared directory won't get such treatment.  It would be great if cp --no-preserve=mode set new file's mode like for plain new files (e. g. created with touch).  Then cp --no-preserve=mode could be used to copy files to the shared directory.

There is a couple of discussions on this topic, so I'm not alone in thinking that current behavior makes little sense.

[1] http://lists.gnu.org/archive/html/bug-coreutils/2003-02/msg00033.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488024
[3] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/144024
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402332
[5] http://karapuz.habrahabr.ru/blog/64868/

Excuse me for linking [5], it is in Russian, but it describes the options to create a shared directory on a Linux computer.  Because cp doesn't support behavior I'm requesting, the author had to conclude that the only working solution is fam (monitoring new files and changing their permissions).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chewi
  • -email is unavailable- added by pixelbeat (Posted a comment)
  • -email is unavailable- added by mjo
  • -email is unavailable- added by markt (Updated the item)
  • -email is unavailable- added by hashproduct (Posted a comment)
  • -email is unavailable- added by hashproduct
  •  

    There are 70 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-09 chewi Carbon-Copy- Added chewi
    2013-01-13 pixelbeat Open/ClosedOpen Closed
    2012-08-07 mjo Carbon-Copy- Added mjo
    2010-02-01 markt Attached File- Added coreutils-fix-no-preserve-mode.diff, #19587
    2009-11-27 hashproduct Carbon-Copy- Added hashproduct

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code