Has 'mv' behaviour changed recently?

Hi,

Something strange happened when I upgraded to Fedora Core 3; when I
type (eg)

[root@computer ~]# mv .tvtime/ /mnt/fatVolume/

I get the error

mv: cannot create directory `/mnt/fatVolume/.tvtime': Permission
denied

This happens even when I call /bin/mv (to bypass aliases etc.) like
so:-

[root@computer ~]# /bin/mv .tvtime/ /mnt/fatVolume/
/bin/mv: cannot create directory `/mnt/fatVolume/.tvtime':
Permission denied

However, when I use the version of mv backed up from my old RH8
installation, it works fine:-

[root@computer ~]# /mnt/linuxBackup/bin/mv .tvtime/
/mnt/fatVolume/
[root@computer ~]#

I can also mkdir directly on /mnt/fatVolume with no errors. Here is the
/etc/fstab entry, for what it's worth:-
/dev/hda5 /mnt/fatVolume vfat umask=000 0
0

The umask=000 was changed from 'default', which has made no difference.

The obvious answer is that the behaviour of 'mv' has changed; but if
so, how?
And if not, what glaringly obvious thing (as I'm sure it will be) am I
missing?

Any help appreciated, thanks!

--

mstrorm@yahoo.co.uk

In comp.os.linux.misc Michael Strorm <mstrorm@yahoo.co.uk>:

> Something strange happened when I upgraded to Fedora Core 3; when I
> type (eg)
[..]

> [root@computer ~]# /bin/mv .tvtime/ /mnt/fatVolume/
> /bin/mv: cannot create directory `/mnt/fatVolume/.tvtime':
> Permission denied

> However, when I use the version of mv backed up from my old RH8
> installation, it works fine:-

> [root@computer ~]# /mnt/linuxBackup/bin/mv .tvtime/
> /mnt/fatVolume/
> [root@computer ~]#

Can you show us the output of:

rpm -Vf /bin/mv

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 314: You need to upgrade your VESA local bus to
a MasterCard local bus.

Michael Heiming wrote:
> Can you show us the output of:
> rpm -Vf /bin/mv

Absolutely nothing at all...

--

mstrorm@yahoo.co.uk

"Michael Strorm" <mstrorm@yahoo.co.uk> writes:

>Michael Heiming wrote:
>> Can you show us the output of:
>> rpm -Vf /bin/mv

>Absolutely nothing at all...

Good that means that rpm has not found that mv has changed since
installation.

Can you copy the file to the new directory?

Bill Unruh wrote:
>Can you copy the file to the new directory?

Yeah, I can cp in place of mv no problem. And I can manually create the
directory that mv says it can't.

--
mstrorm@yahoo.co.uk

In comp.os.linux.misc Michael Strorm <mstrorm@yahoo.co.uk>:
> Bill Unruh wrote:
>>Can you copy the file to the new directory?

> Yeah, I can cp in place of mv no problem. And I can manually create the
> directory that mv says it can't.

Fine, can you try using 'cp -p ...', perhaps 'mv' is trying to
change UIG/GUID on the destination, which doesn't work out, since
there are no on vfat.

You could try running 'strace mv ...' and see where the culprit
is, post a few lines before + after things break, if it doesn't
give you a clue.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 161: monitor VLF leakage

Michael Heiming <michael+USENET@www.heiming.de>,
In a message on Mon, 21 Feb 2005 16:45:06 +0100, wrote :

MH> In comp.os.linux.misc Michael Strorm <mstrorm@yahoo.co.uk>:
MH> > Bill Unruh wrote:
MH> >>Can you copy the file to the new directory?
MH>
MH> > Yeah, I can cp in place of mv no problem. And I can manually create the
MH> > directory that mv says it can't.
MH>
MH> Fine, can you try using 'cp -p ...', perhaps 'mv' is trying to
MH> change UIG/GUID on the destination, which doesn't work out, since
MH> there are no on vfat.

Right. mv wants to 'preserve' ownership and permissions, which not
might be possible on the destination file system (for various reasons).
cp can be less 'anal' about preserving this sort of info.

MH>
MH> You could try running 'strace mv ...' and see where the culprit
MH> is, post a few lines before + after things break, if it doesn't
MH> give you a clue.
MH>
MH> --
MH> Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
MH> mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
MH> #bofh excuse 161: monitor VLF leakage
MH>

\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

Michael Heiming <michael+USENET@www.heiming.de> wrote in message news:<29cpe2-8at.ln1@news.heiming.de>...
> Fine, can you try using 'cp -p ...', perhaps 'mv' is trying to
> change UIG/GUID on the destination, which doesn't work out, since
> there are no on vfat.

cp -pr .tvtime /mnt/dosDrive

Does work without complaint. (Note: The r is necessary as this is a
directory)

> You could try running 'strace mv ...' and see where the culprit
> is, post a few lines before + after things break, if it doesn't
> give you a clue.

I decided to compare the output from the 'normal' installed mv with
the (more successful) mv copied from RH8. The most notable thing was
the difference in return status from what is apparently the "same"
call to mkdir; it failed in the new mv and bailed out. Here are some
lines from the strace on the 'new' mv:-


stat64("/mnt/dosdrive/.tvtime", 0xfefa8d50) = -1 ENOENT (No such file
or directory)
lstat64(".tvtime", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
lstat64("/mnt/dosdrive/.tvtime", 0xfefa8c40) = -1 ENOENT (No such file
or directory)
rename(".tvtime", "/mnt/dosdrive/.tvtime") = -1 EXDEV (Invalid
cross-device link)
unlink("/mnt/dosdrive/.tvtime") = -1 ENOENT (No such file or
directory)
lgetxattr(".tvtime", "security.selinux", "root:object_r:user_home_t",
255) = 26
open("/proc/self/attr/fscreate", O_RDWR) = 3
write(3, "root:object_r:user_home_t\0", 26) = 26
close(3) = 0
mkdir("/mnt/dosdrive/.tvtime", 040777) = -1 EACCES (Permission denied)


And here is the corresponding (AFAICT) part from the 'old' mv:-


ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
....}) = 0
stat64("/mnt/dosdrive/.tvtime", 0xfefff8a0) = -1 ENOENT (No such file
or directory)
lstat64(".tvtime", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
lstat64("/mnt/dosdrive/.tvtime", 0xfefff760) = -1 ENOENT (No such file
or directory)
rename(".tvtime", "/mnt/dosdrive/.tvtime") = -1 EXDEV (Invalid
cross-device link)
unlink("/mnt/dosdrive/.tvtime") = -1 ENOENT (No such file or
directory)
mkdir("/mnt/dosdrive/.tvtime", 040777) = 0

Spot the difference at the end. However, I can't figure out *why* the
call fails in one and not the other. The obvious point is that in the
new mv, there are some extra calls; something to do with getting
extended attributes and secure Linux.

Hmmmmm......

--

mstrorm@yahoo.co.uk

In comp.os.linux.misc Michael Strorm <mstrorm@yahoo.co.uk>:
> Michael Heiming <michael+USENET@www.heiming.de> wrote in message news:<29cpe2-8at.ln1@news.heiming.de>...
[..]

>> You could try running 'strace mv ...' and see where the culprit
>> is, post a few lines before + after things break, if it doesn't
>> give you a clue.

> I decided to compare the output from the 'normal' installed mv with
> the (more successful) mv copied from RH8. The most notable thing was
> the difference in return status from what is apparently the "same"
> call to mkdir; it failed in the new mv and bailed out. Here are some
> lines from the strace on the 'new' mv:-

[..]

> lgetxattr(".tvtime", "security.selinux", "root:object_r:user_home_t",
> 255) = 26

Disable selinux at first and see if this helps.

[..]

> Spot the difference at the end. However, I can't figure out *why* the
> call fails in one and not the other. The obvious point is that in the
> new mv, there are some extra calls; something to do with getting
> extended attributes and secure Linux.

I'd check "getfacl" for any attributes and remove them, but first
disable selinux, IIRC there's some lilo/grub append line to do
this.

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 8: static buildup