[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] stat() and blocks



Hi Vincent, in this old thread from the mint-list you will find some explanations.

http://groups.google.es/group/muc.lists.mint/browse_thread/thread/2dcafd300ad95de5/76a84f49f70a42af?hl=es&ie=UTF-8&q=xattr%2Bmint%2Bblock%2Bsize&pli=1

2009/8/27 Vincent Rivière <vincent.riviere@freesbee.fr>
Hello.

I'm currently running FreeMiNT with hostfs on ARAnyM on Windows.
When running "ls -l", I noticed that the value of the "total" on the first line was far too high. This value is intended to be the sum of the blocks used by the files listed.

The number of blocks use by a file can be retrieved by the stat() function. The correct value is retrieved by Cygwin. It is correctly read by ARAnyM through the natfeats. It is correctly read by the hostfs driver. And finally I found some strange code in the MiNTLib.

The source file is here:
http://sparemint.atariforge.net/cgi-bin/cvsweb/mintlib/mintlib/do_fstat.c?rev=1.4&content-type=text/x-cvsweb-markup
In the function __sys_fstat(), we can see the following code:

long
__sys_fstat (short fd, struct stat *st, int exact)
{
...
struct xattr xattr;
r = Fcntl (fd, &xattr, FSTAT);
...
st->st_blocks = (off_t) (((off_t) xattr.st_blocks
                        * (off_t) xattr.st_blksize) >> 9);
st->st_blksize = xattr.st_blksize;

We can see that most of the values are directly copied from the xattr structure to the stat structure. But there is this hack for the block size. The number of bytes is computed with (xattr.st_blocks * xattr.st_blksize) then the result is divided by 512 (with >> 9), so we obtain the number of 512-byte blocks.
But the original st_blksize is kept as is, it should be forced to 512 so be correct.

On ARAnyM/Cygwin I have st_blksize = 65535. It is 128 actually times 512 bytes. And if I compile a small program calling stat() and showing the value of st_blocks, it is 128 times bigger in MiNT that in Cygwin for the same file, while st_blksize remains the same.

I don't know why it has been hacked like this in the MiNTLib, but it seems wrong. I see 2 solutions:
- Force st->st_blksize to 512, so the value of (st_blocks * st_blksize) will be correct.
- Keep the orignal values of st_blocks and st_blksize

I really prefer the second solution. I don't see why it could be useful to masquerade the block size, especially at the MiNTLib level. Maybe to fix some bogus software assuming a 512 bytes block size ? It is certainly a bad idea, because it is not always the case in the read world.

So I would simply propose:
st->st_blocks = xattr.st_blocks;
st->st_blksize = xattr.st_blksize;
(with the relevant casts, if required).
Then the "total" value of "ls -l" output will be the same in MiNT as in Cygwin for the same directory.

--
Vincent Rivière