bug#15328: Bug or dubious feature?
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.
bug#15328: Bug or dubious feature?
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.
bug#15328: Bug or dubious feature?
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
bug#15328: Bug or dubious feature? (coreutils consistency prob)
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/.
bug#15328: Bug or dubious feature?
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.
bug#15328: Bug or dubious feature?
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/1275825.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.
