Following are responses from "ls" on a file, partition.img, which is a partition image I created using "dd". While being created, as this file got large, the target partition disappeared until I rebooted (a Linux problem, surely, and I mention this only for the full context of the following "ls" result). Upon rebooting, the resulting filesize listed with "ls" is inconsistent, ls -h -l partition.img -rw-r--r-- 1 root root 255G 2006-10-24 23:10 partition.img ls -l partition.img -rw-r--r-- 1 root root 272751509504 2006-10-24 23:10 partition.img Presuming the filesize to be 272,751,509,504, then "ls -h -l" should return 272G not 255G Perl affirms (although it might use the same underlying OS command) the 272G value, perl -e 'print -s "partition.img", "\n"' 272751509504 One would expect that both "ls -h -l" and "ls -l" use the same underlying number, merely printing diffently, so I'm surprised to see different numbers with and without "-h".
Possibly, the value 255G represents an acutal filesize of 256GB, a possible limit from some source, in which case 272G could be wrong. Following are correct responses from "ls" on a file I created of exactly 2.2 GB (dd if=/dev/zero of=zero-test bs=1000 count=2200000), ls -l zero-test -rw-r--r-- 1 root root 2200000000 2006-10-25 09:51 zero-test ls -h -l zero-test -rw-r--r-- 1 root root 2.1G 2006-10-25 09:51 zero-test These results are consistent, although one might prefer "ls -h -l" to give 2.2G rather than 2.1G. The "ls" version from "ls --version" is ls (GNU coreutils) 5.97 I run Debian Linux (version etch), up-to-date on all packages thru 10/23/2006. --Jim Burt _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils