Apparently 'cp -p' invokes 'chown'. When the file list to 'cp -p' has a
file with embedded hyphens in its name, 'chown' complains: 'cp: chown:
../Figs 1-3.pdf: Invalid argument'. Both cp and chown man pgs say they
strive for posix 2.0. Not sure what that means wrt this side-effect.

All this with obsd3.4 (still waiting for 3.5cd).

MK

M Khomo <mkhomo@ostecs.com> wrote in news:c76meb01740@news2.newsguy.com:

> Apparently 'cp -p' invokes 'chown'.

No, it uses chown(2) and chmod(2).

> When the file list to 'cp -p' has a file with embedded hyphens in its
> name, 'chown' complains: 'cp: chown: ./Figs 1-3.pdf: Invalid argument'.

Can't repeat it. Can you show the exact command you used and a 'ls -l' on
the files? Did you copy the files to a local disk or over nfs?

--
Peter Strömberg
C2K2 C2K3 ISCCIV02 ISCCIV03

On Mon, 03 May 2004 18:59:39 -0500, M Khomo wrote:

> Apparently 'cp -p' invokes 'chown'. When the file list to 'cp -p' has a
> file with embedded hyphens in its name, 'chown' complains: 'cp: chown:
> ./Figs 1-3.pdf: Invalid argument'.

Sorry, a bit stupid, I'm not clear what you want to do.
Here I didn't get further than

# ls -l 1-3.pdf
-rw-r--r-- 1 udippel udippel 24 May 4 22:15 1-3.pdf
# cp -p 1-3.pdf /home/wira/
# ls -l /home/wira/
total 199820
-rw-r--r-- 1 wira wira 768 Nov 6 19:07 .cshrc
-rw-r--r-- 1 wira wira 317 Nov 6 19:07 .login
-rw-r--r-- 1 wira wira 11 Jan 4 11:02 .mailboxlist
-rw-r--r-- 1 wira wira 105 Nov 6 19:07 .mailrc
-rw-r--r-- 1 wira wira 199 Nov 6 19:07 .profile
-rw------- 1 wira wira 126 Nov 6 19:07 .rhosts
-rw-r--r-- 1 udippel udippel 24 May 4 22:15 1-3.pdf
-rw------- 1 wira wira 5601 Mar 11 18:14 Sent

# exit
$ rm .mailrc
$ ls -l .m*
-rw-r--r-- 1 udippel udippel 23 Jan 11 17:44 .mailboxlist
$ cp -p /home/wira/.mailrc .
$ ls -l .m*
-rw-r--r-- 1 udippel udippel 23 Jan 11 17:44 .mailboxlist
-rw-r--r-- 1 udippel udippel 105 Nov 6 19:07 .mailrc

man cp:
-p Preserve in the copy as many of the modification time, access
time, file flags, file mode, user ID, and group ID as allowed by
permissions.

If the user ID and group ID cannot be preserved, no error message
is displayed and the exit value is not altered.

Uwe Dippel wrote:
> On Mon, 03 May 2004 18:59:39 -0500, M Khomo wrote:
>
>
>>Apparently 'cp -p' invokes 'chown'. When the file list to 'cp -p' has a
>>file with embedded hyphens in its name, 'chown' complains: 'cp: chown:
>>./Figs 1-3.pdf: Invalid argument'.
>
>
> Sorry, a bit stupid, I'm not clear what you want to do.
> Here I didn't get further than
>
> # ls -l 1-3.pdf
> -rw-r--r-- 1 udippel udippel 24 May 4 22:15 1-3.pdf
> # cp -p 1-3.pdf /home/wira/
> # ls -l /home/wira/
> total 199820
> -rw-r--r-- 1 wira wira 768 Nov 6 19:07 .cshrc
> -rw-r--r-- 1 wira wira 317 Nov 6 19:07 .login
> -rw-r--r-- 1 wira wira 11 Jan 4 11:02 .mailboxlist
> -rw-r--r-- 1 wira wira 105 Nov 6 19:07 .mailrc
> -rw-r--r-- 1 wira wira 199 Nov 6 19:07 .profile
> -rw------- 1 wira wira 126 Nov 6 19:07 .rhosts
> -rw-r--r-- 1 udippel udippel 24 May 4 22:15 1-3.pdf
> -rw------- 1 wira wira 5601 Mar 11 18:14 Sent

Hmmm,
Maybe the embedded space also is involved. Perhaps it was a genuine
permissions problem and the hyphen was circumstantial/coincidental. I
was copying a PC file with embedded spaces and hyphens from an ffs
partition to an msdos partition. Its name was actually 'Figs 1-3.pdf'.
Perhaps the destination mount had genuine permission problems I'll check
and report back. Again, I was on obsd3.4.

OK Here goes:

I can replicate what you demonstrate:
> prompt> cp -p *.pdf /tmp
> prompt> ls /tmp/*.pdf
> Figs 1-5.pdf
> tmprules-1.dat
> prompt> rm /tmp/*.pdf
> prompt> su
> Password:
> host# ls *.pdf
> Figs 1-5.pdf
> host# chgrp wheel *.pdf
> host# exit
> host# exit
> prompt> cp -p *.pdf /tmp
> prompt> ls -l /tmp/*.pdf
> total 144
> -rw-r--r-- 1 mkhomo wheel 70815 May 3 18:34 Figs 1-5.pdf
> prompt> rm /tmp/*.pdf

NB: slightly different issue is why the file took up 'wheel' group to
which mkhomo is member. It was created by a mozilla download.


Then I can replicate what I reported:
> prompt> su
> Password:
> host# mount
> /dev/wd0a on / type ffs (local)
> /dev/wd0g on /home type ffs (local, nodev, nosuid)
> /dev/wd0e on /usr type ffs (local, nodev)
> /dev/wd0f on /usr/local type ffs (local, nodev)
> /dev/wd0d on /var type ffs (local, nodev, nosuid)
> host# mount /dev/wd0k /mnt
> host# ls /mnt/tmp
> ls: /mnt/tmp: No such file or directory
> host# mkdir /mnt/tmp
> host# cp -p *.pdf /mnt/tmp
> cp: chown: /mnt/tmp/Figs 1-5.pdf: Invalid argument
> host# ls /mnt/tmp
> Figs 1-5.pdf
> host# ls -l /mnt/tmp
> total 72
> -rwxr-xr-x 1 root wheel 70815 May 4 13:46 Figs 1-5.pdf
> host#

As before, the copy does happen, but 'chown' (2), almost seems to be
parsing the file name like multiple args with optargs. Could be a
semantically misleading error message since your scenario indicates
chown(2) does handle the filename and permission preservation properly.
Whatever permission problems in the transformation from unix perms to
msdos perms should have triggered an error.

NB2: The msdos mount gives the mounted fs root/wheel, maybe the nearest
thing to the NT Administrator permissions??

M Khomo wrote:

>> host# chgrp wheel *.pdf
>> host# exit
>> host# exit
>> prompt> cp -p *.pdf /tmp
>> prompt> ls -l /tmp/*.pdf
>> total 144
>> -rw-r--r-- 1 mkhomo wheel 70815 May 3 18:34 Figs 1-5.pdf
>> prompt> rm /tmp/*.pdf
>
>
> NB: slightly different issue is why the file took up 'wheel' group to
> which mkhomo is member. It was created by a mozilla download.

Ignore this part. I obviously forget what I do a minute after doing it.
My humble (or should I say proud) contribution to stupidage. I was
changing groups to match the msdos /mnt group. The msdos user'was/is
still root. I suppose the msdos mount refuses to set unknown uid mkhomo,
and hence a genuine perms problem with -p.

On Tue, 04 May 2004 14:15:01 -0500, M Khomo wrote:

> Hmmm,
> Maybe the embedded space also is involved. Perhaps it was a genuine
> permissions problem and the hyphen was circumstantial/coincidental. I
> was copying a PC file with embedded spaces and hyphens from an ffs
> partition to an msdos partition. Its name was actually 'Figs 1-3.pdf'.
> Perhaps the destination mount had genuine permission problems I'll check
> and report back. Again, I was on obsd3.4.

Me too. But now I'm not. Someone will flame me and consider this
irrelevant, but that is up to that someone else.

$ cd /tmp
udippel@debian:/tmp$ echo This is something > 'Figs 1-5.pdf'
udippel@debian:/tmp$ ls -l Figs\ 1-5.pdf
-rw-r--r-- 1 udippel root 18 May 5 15:38 Figs 1-5.pdf
udippel@debian:/tmp$ cat Figs\ 1-5.pdf
This is something
udippel@debian:/tmp$

debian:/tmp# mount -t msdos /dev/hda10 /mnt/homeRH/
debian:/tmp# mount
[...]
/dev/hda10 on /mnt/homeRH type msdos (rw)
debian:/tmp# ls -l /mnt/homeRH/tmp/
total 0
debian:/tmp# ls -l Figs\ 1-5.pdf
-rw-r--r-- 1 udippel root 18 May 5 15:38 Figs 1-5.pdf
debian:/tmp# ls -l /mnt/homeRH/tmp
total 0
debian:/tmp# cp -p *.pdf /mnt/homeRH/tmp/
cp: failed to preserve ownership for `/mnt/homeRH/tmp/figs 1-5.pdf': Operation not permitted
debian:/tmp# ls -l /mnt/homeRH/tmp
total 8
-rwxr--r-- 1 root root 18 May 5 15:38 figs 1-5.pdf
debian:/tmp# cat /mnt/homeRH/tmp/figs\ 1-5.pdf
This is something
debian:/tmp#


There is a distinct desire to not preserve ownership here as well.

This doesn't help too much, I simply became curious after your post and
don't have an OpenBSD with MSDOS-Partition about.

Uwe Dippel wrote:
> On Tue, 04 May 2004 14:15:01 -0500, M Khomo wrote:
....

>
> There is a distinct desire to not preserve ownership here as well.
>
> This doesn't help too much, I simply became curious after your post and
> don't have an OpenBSD with MSDOS-Partition about.

It's begining to make sense. Under MSDOS all users are root, and as as
such the FAT[32] fs should not acceed to niceties of other fs's that
contravene its limitations/features. I would not have bothered either,
but the text of the error message sent me on the wrong line of thought,
even though in the legal sense, 'Invald Argument' is a valid error
message for chown(2) to report.

MK

On Wed, 05 May 2004 14:28:06 -0500, M Khomo wrote:

> It's begining to make sense. Under MSDOS all users are root, and as as
> such the FAT[32]

Possible. I'd rather think it was slightly different: The mounter was
root; FAT supports no ownership, so actually nothing is written there
w.r.t. ownership.
No indication of ownership in the FAT, the owner defaults to the owner of
the mount. As long as it is mounted.
"failed to preserve ownership for ... " makes a lot of sense here; it
simply cannot because there is no place to write it.
"Operation not permitted" is less convincing. Why should root have such
things ? It could better read: "Operation not possible"

> I would not have bothered either,
> but the text of the error message sent me on the wrong line of thought,
> even though in the legal sense, 'Invald Argument' is a valid error
> message for chown(2) to report.

"cp: chown: /mnt/tmp/Figs 1-5.pdf: Invalid argument"
to me isn't much better compared to the GPL-version above. The argument
isn't invalid in itself. It is fully valid and comprehensible. It only
cannot be implemented, because there is no place to write that info.

That "failed to preserve ownership for ... " seems to be slightly more
informative.

Uwe

Uwe Dippel wrote:
>
> That "failed to preserve ownership for ... " seems to be slightly more
> informative.
>
> Uwe

Agreed.

MK