Jameson C. Burt wrote:
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
Nope, actually if ls is doing anything wrong, it is that it is rounding
(approx) 254.02G up to 255G.
272751509504 / (1024^3) = 254.019638...G
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.
2200000000 / (1024^3) = 2.0489...G, or 2.1G (again, explicitly rounding up).
Hint:
1 kB = 1024 bytes
1 MB = 1024 kB
1 GB = 1024 kB
Next time try reading the man page, especially the option '--si' right
under '-h'.
--
Matthew
When on POSIX, do as POSIX mandates.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
