Re: [coreutils] Bug in du with -x flag?

2013-04-06 Thread Andrey Repin
Greetings, Dave Korn!


 Hi list,

   I always used to use du with the -cxhs options, but since updating to the
 latest (8.15-1) version there appears to be a problem caused by -x:

 $ ls -la
 total 392188
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  6 00:35 .
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 05:58 ..
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 16:28 gcc4
 -rw-r--r--  1 DKAdmin None 40157 Apr  6 00:43 gcc472-2-dist.tar.bz2
 
 $ du -xh gcc472-2-dist.tar.bz2
 
 $ du -h gcc472-2-dist.tar.bz2
 383Mgcc472-2-dist.tar.bz2
 
 $

   Unless I'm misunderstanding it badly, -x shouldn't make any difference when
 counting a real file in the current directory.  I wonder if it could have
 perhaps been introduced by the recent related bugfix that I read about in
 /usr/share/doc/coreutils/NEWS:

   du -x no longer counts root directories of other file systems.
   [bug introduced in coreutils-5.1.0]

 or perhaps some interaction between that and Cygwin's path conversion code?

40157/1024/1024 = 382.985Mb
Seems proper to me.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 06.04.2013, 15:47

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: [coreutils] Bug in du with -x flag?

2013-04-06 Thread Ryan Johnson

On 06/04/2013 7:48 AM, Andrey Repin wrote:

Greetings, Dave Korn!



 Hi list,
   I always used to use du with the -cxhs options, but since updating to the
latest (8.15-1) version there appears to be a problem caused by -x:

$ ls -la
total 392188
drwxr-xr-x+ 1 DKAdmin None 0 Apr  6 00:35 .
drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 05:58 ..
drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 16:28 gcc4
-rw-r--r--  1 DKAdmin None 40157 Apr  6 00:43 gcc472-2-dist.tar.bz2

$ du -xh gcc472-2-dist.tar.bz2

$ du -h gcc472-2-dist.tar.bz2
383Mgcc472-2-dist.tar.bz2

$

   Unless I'm misunderstanding it badly, -x shouldn't make any difference when
counting a real file in the current directory.  I wonder if it could have
perhaps been introduced by the recent related bugfix that I read about in
/usr/share/doc/coreutils/NEWS:

   du -x no longer counts root directories of other file systems.
   [bug introduced in coreutils-5.1.0]

or perhaps some interaction between that and Cygwin's path conversion code?

40157/1024/1024 = 382.985Mb
Seems proper to me.
The problem is not the size reported by du -h... it's that du -x doesn't 
list the file at all.


Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: [coreutils] Bug in du with -x flag?

2013-04-06 Thread Andrey Repin
Greetings, Ryan Johnson!

I always used to use du with the -cxhs options, but since updating to the
 latest (8.15-1) version there appears to be a problem caused by -x:
 $ ls -la
 total 392188
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  6 00:35 .
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 05:58 ..
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 16:28 gcc4
 -rw-r--r--  1 DKAdmin None 40157 Apr  6 00:43 gcc472-2-dist.tar.bz2

 $ du -xh gcc472-2-dist.tar.bz2

 $ du -h gcc472-2-dist.tar.bz2
 383Mgcc472-2-dist.tar.bz2

 $
Unless I'm misunderstanding it badly, -x shouldn't make any difference 
 when
 counting a real file in the current directory.  I wonder if it could have
 perhaps been introduced by the recent related bugfix that I read about in
 /usr/share/doc/coreutils/NEWS:
du -x no longer counts root directories of other file systems.
[bug introduced in coreutils-5.1.0]
 or perhaps some interaction between that and Cygwin's path conversion code?
 40157/1024/1024 = 382.985Mb
 Seems proper to me.
 The problem is not the size reported by du -h... it's that du -x doesn't 
 list the file at all.

Sorry, I misread your original post...


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 07.04.2013, 04:33

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



[coreutils] Bug in du with -x flag?

2013-04-05 Thread Dave Korn

Hi list,

  I always used to use du with the -cxhs options, but since updating to the
latest (8.15-1) version there appears to be a problem caused by -x:

 $ ls -la
 total 392188
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  6 00:35 .
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 05:58 ..
 drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 16:28 gcc4
 -rw-r--r--  1 DKAdmin None 40157 Apr  6 00:43 gcc472-2-dist.tar.bz2
 
 $ du -xh gcc472-2-dist.tar.bz2
 
 $ du -h gcc472-2-dist.tar.bz2
 383Mgcc472-2-dist.tar.bz2
 
 $

  Unless I'm misunderstanding it badly, -x shouldn't make any difference when
counting a real file in the current directory.  I wonder if it could have
perhaps been introduced by the recent related bugfix that I read about in
/usr/share/doc/coreutils/NEWS:

   du -x no longer counts root directories of other file systems.
   [bug introduced in coreutils-5.1.0]

or perhaps some interaction between that and Cygwin's path conversion code?

cheers,
  DaveK


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



bug in du

2005-05-18 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Reini Urban reported a du bug on the cygwin list - using mount points (or
directory hard links on systems that support that) confuses the default
behavior, and files are being double-counted and inflating the actual disk
space in usage.  In the example below, I used cygwin's mount feature to
mount dir3 atop dir1.

 $ ls -iRF
 .:
 14952513712823677584 dir1/  2251799813894795 file1
28147497671275154 dir2/  2251799813894795 file2
 14952513712823677584 dir3/
 
 ./dir1:
 17343925114957410972 file
 
 ./dir2:
 17343925114957410972 file
 
 ./dir3:
 17343925114957410972 file
 $ du
 1   ./dir1 # dir1/file counted...
 0   ./dir2 # ...skipped since st_nlink is 2
 0   ./dir3 # ...skipped since st_nlink is 2
 2   .  # and ./file[12] counted once
 $ du -l  # ...where file was also linked outside linked directories
 1   ./dir1 # dir1/file counted once...
 1   ./dir2 # twice
 1   ./dir3 # third time
 5   .  # plus 2 more for ./file[12]
 $ echo testing  dir3/file3
 $ ls -iRF
 .:
 14952513712823677584 dir1/  2251799813894795 file1
28147497671275154 dir2/  2251799813894795 file2
 14952513712823677584 dir3/
 
 ./dir1:
 17343925114957410972 file  1970324837184162 file3
 
 ./dir2:
 17343925114957410972 file
 
 ./dir3:
 17343925114957410972 file  1970324837184162 file3
 $ du
 2   ./dir1  # dir1/file and dir1/file3 counted
 0   ./dir2  # dir2/file skipped
 1   ./dir3  # dir3/file skipped, but dir3/file3 counted!
 4   .   # and ./file[12] counted once. This total should be 3
 $ du -l
 2   ./dir1 # dir1/file and dir1/file3 counted
 1   ./dir2 # dir2/file counted again
 2   ./dir3 # dir3/file and dir3/file3 counted again
 7   .  # and ./file[12] each counted, for correct total.
 $ ls -l dir1
 total 2
 -rw-r--r--  2 eblake None 8 May 18 06:38 file
 -rw-r--r--  1 eblake None 8 May 18 06:50 file3

One possible fix is revisiting line 377 in src/du.c in CVS, which
currently skips hard links only if a file has multiple links.  The other
fix would be to also check directories for identical inodes, and not
descending through a directory by a second spelling if it has already been
visited once.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi0CL84KuGfSFAYARAlTnAJ95ur2l0LxXXZjNrLPNQrcBIeTX3ACgoe5p
40GmfwNSFZJRZyp0AcWWics=
=N51g
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: bug in du

2005-05-18 Thread Paul Eggert
Eric Blake [EMAIL PROTECTED] writes:

 One possible fix is revisiting line 377 in src/du.c in CVS, which
 currently skips hard links only if a file has multiple links.

Sorry, I don't quite follow this.  Don't all the directories in
question have multiple links?  Or, if you're talking about walking
through the directory multiple times and discarding each file you
find, that sounds pretty slow.

 The other fix would be to also check directories for identical
 inodes, and not descending through a directory by a second spelling
 if it has already been visited once.

That makes more sense to me, anyway: directories should be treated
like other files.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/