GNU bug report logs - #6245
cp - copy files and directories, ls -Rld, chmod

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6245 in the body.
You can then email your comments to 6245 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "estonoeshawaii <at> yahoo.com" <estonoeshawaii <at> yahoo.com>
To: bug-coreutils <at> gnu.org
Subject: cp - copy files and directories, ls -Rld, chmod
Date: Sat, 22 May 2010 00:19:30 -0700 (PDT)

[Message part 1 (text/plain, inline)]

Hi,

1. The copy command  cp -a

-a, --archive
              same as -dpR

-p     same as --preserve=mode,ownership,timestamps

is not doing what it is supposed to do (and thats is fine, of course), because It does not preserve ownership (except if you are root) . The problem is that it doesn't tell you anything when it doesn't do it or that It shouldn't be supposed to preserve ownership.
-------------------
2. Many commands act recursively on a directory with an -R option that affects the directory and all the files it contains.

There should be a

ls -ld -R

command that lists in detail the directory and its contents to quickly check results in one step.
--------------------------------
3. If we have:

drwx------ 2 user2 user2  392 2010-01-11 12:04 /home/user2/directory

user1 <at> mypc:~$ su  -c 'chmod -R 644 /home/user2/directory' user2

doesn't work. You need to change the mode of the directory first and then you can apply a recursive chmod. Is this a bug?

Many thanx for many things.
:-)



      

[Message part 2 (text/html, inline)]

Message #10 received at 6245-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "estonoeshawaii <at> yahoo.com" <estonoeshawaii <at> yahoo.com>
Cc: 6245-done <at> debbugs.gnu.org
Subject: Re: bug#6245: cp - copy files and directories, ls -Rld, chmod
Date: Sat, 22 May 2010 13:34:00 -0600

estonoeshawaii <at> yahoo.com wrote:
> course), because It does not preserve ownership (except if you are
> root) . The problem is that it doesn't tell you anything when it
> doesn't do it or that It shouldn't be supposed to preserve
> ownership.

This is related to this FAQ entry.  It explains why only root can
chown files.

  http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f

The 'cp -a' option says:

  `-a'
  `--archive'
      Preserve as much as possible of the structure and attributes of the
      original files in the copy ...

It is not possible to preserve the ownership of a file unless you are
root.  Therefore cp is preserving "as much as possible".

> 2. Many commands act recursively on a directory with an -R option
> that affects the directory and all the files it contains.
> 
> There should be a
> 
> ls -ld -R
> 
> command that lists in detail the directory and its contents to
> quickly check results in one step.

The -R option is exactly the option you are asking for except you have
explicitly blocked its action by adding the -d option.

  `-R'
  `--recursive'
       List the contents of all directories recursively.

This does what you intend.

  `-d'
  `--directory'
       List just the names of directories, as with other types of files,
       rather than listing their contents.

But you included the -d option that prevents it from recursing.

> 3. If we have:
> 
> drwx------ 2 user2 user2  392 2010-01-11 12:04 /home/user2/directory
> 
> user1 <at> mypc:~$ su  -c 'chmod -R 644 /home/user2/directory' user2
> 
> doesn't work. You need to change the mode of the directory first and
> then you can apply a recursive chmod. Is this a bug?

Mode 644 isn't what you want for directories.  That would remove the
eXecute bit.  The execute permission on a directory allows access to
list the contents of the directory.  If that permission is removed
then the chmod command will not have access to list the directory
contents.

You probably want something that only affects files.  Use find for
that instead.  Try something like this:

  su -c 'find /home/user2/directory -type f -exec chmod 644 {} +' user2

> Many thanx for many things.

When reporting bugs (or at least when reporting what you are thinking
is a bug :-) it is best to report only one item at a time.  Mixing
several items together causes all of them to be treated together as a
group even if they are individually separate.

Since none of these were bugs I am going to go ahead and mark it as
being closed in the bug tracker.  Feel free to follow-up normally if
you have more information.  In the future for general help with the
utilities you might want to ask general help questions in the
help-gnu-utils <at> gnu.org mailing list.

Bob

Message #13 received at 6245 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 6245 <at> debbugs.gnu.org, bob <at> proulx.com
Subject: Re: bug#6245: cp - copy files and directories, ls -Rld, chmod
Date: Sun, 23 May 2010 00:47:00 +0100

On 22/05/10 20:34, Bob Proulx wrote:
> estonoeshawaii <at> yahoo.com wrote:
>> course), because It does not preserve ownership (except if you are
>> root) . The problem is that it doesn't tell you anything when it
>> doesn't do it or that It shouldn't be supposed to preserve
>> ownership.
> 
> This is related to this FAQ entry.  It explains why only root can
> chown files.
> 
>   http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f
> 
> The 'cp -a' option says:
> 
>   `-a'
>   `--archive'
>       Preserve as much as possible of the structure and attributes of the
>       original files in the copy ...
> 
> It is not possible to preserve the ownership of a file unless you are
> root.  Therefore cp is preserving "as much as possible".

I noticed myself that `cp --preserve=owner` does not give an
error when running as non root. A pertinent comment from the source:

  /* If non-root uses -p, it's ok if we can't preserve ownership.
     But root probably wants to know, e.g. if NFS disallows it,
     or if the target system doesn't support file ownership.  */

Perhaps if "owner" is explicitly specified they we should warn?
I'm not sure it's worth diverging the warning characteristics
for this though.

cheers,
Pádraig.

Message #16 received at 6245 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 6245 <at> debbugs.gnu.org
Subject: Re: bug#6245: cp - copy files and directories, ls -Rld, chmod
Date: Sat, 22 May 2010 19:00:30 -0600

Pádraig Brady wrote:
> I noticed myself that `cp --preserve=owner` does not give an
> error when running as non root. A pertinent comment from the source:
> 
>   /* If non-root uses -p, it's ok if we can't preserve ownership.
>      But root probably wants to know, e.g. if NFS disallows it,
>      or if the target system doesn't support file ownership.  */
> 
> Perhaps if "owner" is explicitly specified they we should warn?
> I'm not sure it's worth diverging the warning characteristics
> for this though.

I don't know.  I am not sure I am either for it or against it.  It
seems defensible that --preserve=owner should produce a diagnostic if
it can't actually set the owner.  I couldn't oppose it.  And some
traditional systems such as SysV do allow giving away file ownership.

I know you are not talking about cp -a but I wanted to say that I
often use cp -a to copy files not owned by me into my directory to
make a working copy that I can change.  If it started to produce
errors or warnings that would be bad.  I certainly think that behavior
shouldn't change or it would create a large problem for users.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.