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

 
 

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

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

Submitted by:  None
Submitted on:  Thu 30 Jul 2009 11:57:13 PM UTC  
Votes:  70  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Closed

Sun 13 Jan 2013 10:42:38 PM UTC, comment #4:

Fixed with these:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=24ebca6
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6254357

Pádraig Brady <pixelbeat>
Project 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

 

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 70 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 13 Jan 2013 10:42:38 PM UTCpixelbeatOpen/ClosedOpen=>Closed
    Tue 07 Aug 2012 03:59:55 PM UTCmjoCarbon-Copy-=>Added mjo
    Mon 01 Feb 2010 04:10:59 AM UTCmarktAttached File-=>Added coreutils-fix-no-preserve-mode.diff, #19587
    Fri 27 Nov 2009 09:40:16 PM UTChashproductCarbon-Copy-=>Added hashproduct

    Back to the top


    Powered by Savane 3.1-cleanup