file size listings in GnuWin32 coreutils 5.2.1 doesn't seem right

[stephenc]

Hi,

I've downloaded and installed GnuWin32 coreutils 5.2.1 on 3/22/3005. My
filesystem is NTFS and it was formatted with a block size of 4096 bytes. I
have Windows 2000 with all of Microsoft's patches on a Pentium 4.

I've experimented with ls, vdir, and du to see if I could get a listing of
a file's actual size and can't see how to do it.

the --help option for ls says "--block-size=SIZE use SIZE-byte blocks" but
when I put "--block-size=1" to get a listing in single byte sizes (blocks
in a size of 1 byte), I get some other result.

I don't have any of the block size related environment variables set that
are mentioned in the coreutils help file.

For example I have a file "fontagent.zip" that is 1,260,452 bytes in size
according to Microsoft's dir command. The command

   "ls --block-size=1 -s fontagent.zip"

shows a size of 1,261,568 (which is how many 4K sized blocks it would take
up, right?).

Putting other values in for block-size doesn't seem to work right either.
It really freaks out on some values, and crashed with

 "ls --block-size=140 -s -1".

I made a seven byte file called "test.txt" and did the command

  "ls -s -1 test.txt"

and it returned a size of 4 somethings. I don't think that is bytes (it
would have been 7) or blocks (4*4096 is 16384 bytes). I've no idea what it
is. The command

  "ls --block-size=1 -s -1 test.txt"

returns a size of 4096. I had specified 1 byte blocks so it should have
been a size of 7 instead. OK but that is the number of bytes in my
filesystem's default block size, so I did the command

  "ls --block-size=4096 -s -1 test.txt"

and got a size of 1. OK that seems right, a seven byte file fits in one 4K
block. I tried the command

  "ls --block-size=7 -s -1 test.txt"

and got a size of negative zero somethings. That doesn't seem right. At
the least I would have expected a size of 1 block (one seven byte block).
The command

  "ls --block-size=8 -s -1 test.txt"

gives me a size of 512 somethings. Well, I could have accepted 1 block (a
seven byte file will fit inside an eight byte block) but why is it doing
math (4096/8=512) instead? The command

  "ls --block-size=4097 -s -1 test.txt"

gives me postive zero somethings, not a size 1 block. Entering other
values was kind of entertaining, like

  "ls --block-size=5 -s -1 test.txt"

returning a size of
-822752278660603020000000000000000000000000000000000000000000000
somethings. Why not 2 blocks (one seven byte file fits in 10 bytes worth
of five byte blocks)?

I'm not a programmer, so I think that is about the best that I can do to
show the difference between what is displayed by the commands vs. what I
expected them to display.

The help file for coreutils says in the section about block sizes:

"If none of the above environment variables are set, the block size
currently defaults to 1024 bytes in most contexts, but this number may
change in the future.  For ls file sizes, the block size defaults to 1
byte.

A block size specification can be a positive integer specifying the number
of bytes per block, or it can be human-readable or si to select a
human-readable format...."

This doesn't seem to be true in my case.

Of course, maybe I just don't understand what the option --block-size is
used for or maybe I just have the wrong kind of expectations?

Also, with "ls -si -1" I get some large number listed before each row of
file blocks and filename. I'm not sure what that is, since it doesn't show
with "ls -s -1" and since the -i I believe is supposed to take the file
blocks and round them to the nearest kilobytes, megabytes, etc. to make it
"human friendly".

Thanks,

Stephen Carpenter
address@hidden