du - Value too large to be stored in data type

Re:du - Value too large to be stored in data type (redondo_se)

Tue, 03 Aug 2010 10:28:06 GMT

Yep, that seems to have fixed it. It works now in all cases that it did not before.

Thanks!!

Sean

Re:du - Value too large to be stored in data type (Rodney)

Tue, 03 Aug 2010 05:06:59 GMT

Okay, I've shifted the patch/workaround a bit do it works when files aren't named. "pkg_update -L du" to give it a try. Thanks.

Re:du - Value too large to be stored in data type (redondo_se)

Sat, 31 Jul 2010 16:38:29 GMT

Rodney

There's an updated du now.
Do "pkg_update -L du" to get it installed.
Let me know if there is any problem still.

Hi Rodney,

I'm not getting email updates when you reply to this thread, even though I have it as a subscription with instant email notification.

Anyway, I was wrong earlier when I said it was working on the 500 GB drive but not the 2TB drive. It's actually wrong on both. I think version 1.0 has the same problem, it just doesn't give the "value too large" message.

I just tried your update, and unfortunately it's still not quite right. It seems that "du -hsc *" give the right answer, but du -h does not. And using * won't work if there are directories that begin with ".".

 /dev/fs/F/BACKUP > ls -Flh 
     total 644391 
     -rwxrwx---+ 1 +SYSTEM  +SYSTEM   100M Jun  3 03:13 cindy_boot_partition.tib* 
     -rwxrwx---+ 1 +SYSTEM  +SYSTEM   4.2G Jun  3 02:31 cindy_test_backup.tib* 
     /dev/fs/F/BACKUP > du -hsc * 
     100M    cindy_boot_partition.tib 
     4.2G    cindy_test_backup.tib 
     4.3G    total 
     /dev/fs/F/BACKUP > du -h 
     8.0P    .

Thanks for giving it some attention.
Sean
edit: just tried in another directory with more large files, and -hsc * does not work correctly there.

Re:du - Value too large to be stored in data type (Rodney)

Thu, 29 Jul 2010 21:32:20 GMT

There's an updated du now.
Do "pkg_update -L du" to get it installed.
Let me know if there is any problem still.

Re:du - Value too large to be stored in data type (Rodney)

Thu, 29 Jul 2010 19:06:13 GMT

Yeah, it's a subsystem bug. It's likely a casting thing.
I can do a workaround in du to calculate it right.

Re:du - Value too large to be stored in data type (Rodney)

Thu, 29 Jul 2010 18:17:02 GMT

It's something more confusing then I thought it would be.
It's looking like the information returned from the stat(2) system call on 64-bit systems has the number
of blocks used wrong. The number of blocks reported is to use a block size of 512 (regardless of
the actual block size used on the device).

Re:du - Value too large to be stored in data type (Rodney)

Thu, 29 Jul 2010 15:54:43 GMT

The message from du 1.0.1 is likely the best clue.
A 32 bit integer will hold a value to 4G before rolling over.
So that 4.2G versus 214M makes sense in that context.

I'll go look at du right now.

Re:du - Value too large to be stored in data type (redondo_se)

Thu, 29 Jul 2010 10:42:54 GMT

Wasn't thinking correctly when I made that last post. Actually, all my drives are encrypted with Truecrypt, so the size seems to be the only difference.

Re:du - Value too large to be stored in data type (redondo_se)

Thu, 29 Jul 2010 10:09:36 GMT

Rodney

Glad you were able to fix it.

The 32-bit based utilities will install on the 64-bit systems and usually it'll be alright.
There is a separate bundle with just 64-bit utilities too.
When installing the utilities on a one-by-one basis the installer will pick the 64-bit package
first, if it is available, otherwise the 32-bit.

Actually, I did install the 64-bit bundle. However, things are not all well as I had thought. df is working correctly, but du is still giving me some strange results:

 /dev/fs/F/BACKUP > ls -Fhl
 total 644391
 -rwxrwx---+ 1 +SYSTEM  +SYSTEM   100M Jun  3 03:13 cindy_boot_partition.tib*
 -rwxrwx---+ 1 +SYSTEM  +SYSTEM   4.2G Jun  3 02:31 cindy_test_backup.tib*
 
 /dev/fs/F/BACKUP > du -ha
 100M    ./cindy_boot_partition.tib
 214M    ./cindy_test_backup.tib
 314M    .

Notice that ls reports the correct size of cindy_test_backup.tib, but du does not. I no longer get the value too large errors, but it's not correct in this case.

du does work correctly on large files on another drive. However, notable differences are that the other drive is only a 500 GB drive. The drive that I get bad numbers on is 2TB, and is also encrypted with truecrypt.

The du-1.0.1 package is the one that gives me the value too large errors. The du that comes with the microsoft utilities and the du-1.0 package from the tool warehouse both give me the same bad numbers for this large file on my 2TB drive.

Is there an alternative to du to find the disk usage of directories?

Thanks,
Sean

Re:du - Value too large to be stored in data type (Rodney)

Wed, 28 Jul 2010 17:40:29 GMT

Glad you were able to fix it.

The 32-bit based utilities will install on the 64-bit systems and usually it'll be alright.
There is a separate bundle with just 64-bit utilities too.
When installing the utilities on a one-by-one basis the installer will pick the 64-bit package
first, if it is available, otherwise the 32-bit.

Re:du - Value too large to be stored in data type (redondo_se)

Wed, 28 Jul 2010 10:27:41 GMT

Fixed it. After some digging, I realized that I installed the older Utilities and SDK, the one intended for Server 2008 and Vista RTM. I didn't realize there was a newer version for 2008 R2 and Windows 7. I had also done the full tools warehouse package install.

I uninstalled everything including the SUA services, and started clean. This time I installed the newer Utilities and SDK, and I'm taking a more minimal approach to installing things from the warehouse this time.

du and df are both working correctly now.

du - Value too large to be stored in data type (redondo_se)

Mon, 26 Jul 2010 13:43:54 GMT

Hi,

I'm running windows server 2008 R2 64-bit. I have installed SUA and the full Interix package. uname -a produces the following:

Interix cindy 6.1 10.0.6030.0 genuineintel Intel64_Family_6_Model_15_Stepping_11

I get "Value too large to be stored in data type" on large files when I execute du. Also, df -h is off by a factor of 1000, i.e. the values output are too small. df -g outputs the correct values though. One of my disks is a 2TB disk with 1 large volume.

Is there any way to fix these issues?

Thanks,
Sean