GNU bug report logs - #15328
Bug or dubious feature?

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 15328 in the body.
You can then email your comments to 15328 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: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: Bug or dubious feature?
Date: Tue, 10 Sep 2013 13:48:37 -0700

I was trying to move a directory with the 'mv' command.

Instead of renaming the files it copied and deleted them.

The source and destination were the same disk which a stat of the source
and destination would confirm.

The "oddity", is that I was moving between
/usr/share/fonts -> /home/law/fonts where I use "rbind" to mount
part of home in /usr/share:


(fstab)
/home/share /usr/share  none  rbind

stat shows:


> stat -c %D /usr/share /home/share
fe03
fe03


So... why didn't it rename if the device numbers are the same?

I'm sure it wouldn't try a rename if I moved from /usr->/usr/share as
share is a different partition/device number, so it seems 'mv' does check
device id's to verify sameness upon move.  Then why not in moving
what was "effectively", /home/share/fonts/<dirname> => /home/law/fonts/. ?

It was only 12G of files, so it was done in ~ 5-10 minutes, but I was
expecting a few seconds...??

Coreutils 8.21/linux 3.9.11 / xfs filesystem.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: 15328 <at> debbugs.gnu.org
Subject: Re: bug#15328: Bug or dubious feature?
Date: Tue, 10 Sep 2013 14:01:21 -0700

Whatever the problem is, it's not in 'mv'...

I tried to run my dedup'r, and got this:
  /usr/share/fonts/sys> time ndedup /home/law/fonts/sys2/ .
  Paths: 34474, uniq nodes: 20192, total_size: 12.8GB (12.9GB allocated).
  ERROR: Invalid cross-device link doing link(./desktop.ini, 
/home/law/fonts/sys2//desktop.ini): \
    (Invalid cross-device link) at /home/law/bin/ndedup line 1107
  10.40sec 10.11usr 0.28sys (99.98% cpu)
----

But this works (same dir's):

  /usr/share/fonts/sys> cd /home/share/fonts/sys
  /home/share/fonts/sys> time ndedup /home/law/fonts/sys2/ .
  Paths: 34474, uniq nodes: 20191, total_size: 12.8GB (12.9GB allocated).
   Nodes(done/uniq); Space(read / alloc'd)
    35011/12758    25.5GB / 7.2GB space  ;cursz:  37.8MB; newlnks: 7433(1730 
cmps_skip, 11046 cmps_full)
  5.7GB in 7434 duplicate files found found.
  49.75sec 35.34usr 12.90sys (96.98% cpu)

Anyone know if this is a documented kernel "feature"?
Seems odd.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: 15328 <at> debbugs.gnu.org
Subject: Re: bug#15328: Bug or dubious feature? (coreutils consistency prob)
Date: Wed, 11 Sep 2013 16:00:04 -0700

Linda Walsh wrote:
> 
> Whatever the problem is, it's not in 'mv'...
----
	But there is a consistency problem in core utils.

Even though /usr/share/fonts and /home/share/fonts are the same directory
with /home/share being mounted with "rbind" on /usr/share,

"mv" cannot move files between the two dirs without copying them.  That
"might" be ok, except that "du -sh /usr/share/fonts /home/share/fonts/"
sees them as 1 directory.

Why does "mv" fail to rename (vs. physical copy) when "du" sees them
as the same directory -- (and only lists the first one if trying to du both):

  Ishtar:/> du -sh /home/share/fonts/. /usr/share/fonts/.
  8.8G    /home/share/fonts/.
  Ishtar:/> du -sh /usr/share/fonts/. /home/share/fonts/.
  8.8G    /usr/share/fonts/.

---

Also, is it intentional to leave out args from the listing of "du" --
I know it doesn't double-count the space (by default), but I would have
thought to see a 2nd entry w/0 space:

  Ishtar:/> du -sh /home/share/fonts/. /usr/share/fonts/.
  8.8G    /home/share/fonts/.
  0       /usr/share/fonts/.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Subject: Re: bug#15328: Bug or dubious feature?
Date: Fri, 11 Jan 2019 02:20:00 -0700

tags 15328 notabug
close 15328
stop

Hello,

On 2013-09-10 3:01 p.m., Linda Walsh wrote:
> Whatever the problem is, it's not in 'mv'...

Given the above, and no further comments in 5 years,
I'm closing this item.

regards,
 - assaf

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#15328: Bug or dubious feature?
Date: Sat, 19 Jan 2019 17:03:24 -0800

On 1/11/2019 1:20 AM, Assaf Gordon wrote:
> tags 15328 notabug
> close 15328
> stop
> 
> Hello,
> 
> On 2013-09-10 3:01 p.m., Linda Walsh wrote:
>> Whatever the problem is, it's not in 'mv'...
> 
> Given the above, and no further comments in 5 years,
> I'm closing this item.
----
	There were further comments but, some
Erik/eric, the cygwin person supporting core utils 
at the time refused to 
allow me to process the bugs through core utils 
before being "ok'd" / triaged by the cygwin interface
person(him).

This was a very serious bug that appeared in several
other areas where "update" conflicted with read-only
settings on sources that caused deletion of data off of
sources that were marked as 'read-only'.

Of course even after telling him how he could reproduce
the bug on linux using the "ignore case" feature on XFS, he
couldn't be bothered.

I also got ignored when mentioning this was related to the
"file changed as we read it" bug that kept resurfacing on
some filesystem that never became stable enough on linux for
a first release.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>, assafgordon <at> gmail.com,
 15328 <at> debbugs.gnu.org
Subject: Re: bug#15328: Bug or dubious feature?
Date: Sun, 20 Jan 2019 10:09:15 -0800

L A Walsh wrote:
> This was a very serious bug that appeared in several
> other areas

Yes, this appears to be a mount problem that affects many programs, not a 
coreutils problem per se.

The discrepancy that you observed between "mv" and "du" could be explained by 
the fact that "mv a/b c/d" changes C and also looks at A's and C's device 
number, whereas "du a/b c/d" needs to look only at A/B's and C/D's device 
number. So I don't see a bug. And anyway, the mount is the real problem here.

Previous Next

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