From mint-bounce@lists.fishpool.fi Thu Aug 27 05:47:24 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=b9ngB/qhFxsZSUp+lxDsCe621mlB8AYaNX5bLC262Jk=; b=KLhzmZ7rTDcVPcW5uvVhXOHepft6g50mDdvHsn+T272iaqjGiqKEv/DOTnzIOTIQvP DghcI5rDSPcFl8UMxA885rMm+1UAcHZRE2JS6/VFv5bTeN4kdsVQbHQLgbPjsZhspq6K r5G1ReWZe23FiwaF5jEdiS3CPx+aFhT9eNUoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sbYL0h3L2cEXF5GduFHTaCz38yoRaSQ+l0sSJxXPbU+E+Wp9iRdRxcGVPcoiG0k7KA v+MEFxWxQruL5AC49K9CdhGfArybHJZPP+GejRRGyfJmOZV+e3ZhEL0dWIzHioh2aR8R +DuzF7yd40eF8AWFj3K2lKn2gUVAVj6uzewfY= MIME-Version: 1.0 In-Reply-To: <4A95B430.9080304@freesbee.fr> References: <4A95B430.9080304@freesbee.fr> Date: Thu, 27 Aug 2009 11:41:24 +0200 Message-ID: <8cf5b8cc0908270241p4ebc59d8yc8b2b9380972cf90@mail.gmail.com> Subject: Re: [MiNT] stat() and blocks From: =?ISO-8859-1?Q?David_G=E1lvez?= To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= Cc: mint@lists.fishpool.fi Content-Type: multipart/alternative; boundary=001636ed667af8aa4c04721c5e50 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: dgalvez75@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: --001636ed667af8aa4c04721c5e50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/2dcafd300= ad95de5/76a84f49f70a42af?hl=3Des&ie=3DUTF-8&q=3Dxattr%2Bmint%2Bblock%2Bsize= &pli=3D1 2009/8/27 Vincent Rivi=E8re > 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 firs= t > 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() functio= n. > 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 fina= lly > 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=3D1.4&content-type=3Dtext/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 =3D Fcntl (fd, &xattr, FSTAT); > ... > st->st_blocks =3D (off_t) (((off_t) xattr.st_blocks > * (off_t) xattr.st_blksize) >> 9); > st->st_blksize =3D 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 siz= e. > 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 =3D 65535. It is 128 actually times 51= 2 > bytes. And if I compile a small program calling stat() and showing the va= lue > 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 seem= s > 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 t= o > 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 b= ad > idea, because it is not always the case in the read world. > > So I would simply propose: > st->st_blocks =3D xattr.st_blocks; > st->st_blksize =3D 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=E8re > > > --001636ed667af8aa4c04721c5e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vincent, in this old thread from the mint-list you will find some explan= ations.

http://groups.google.es/gro= up/muc.lists.mint/browse_thread/thread/2dcafd300ad95de5/76a84f49f70a42af?hl= =3Des&ie=3DUTF-8&q=3Dxattr%2Bmint%2Bblock%2Bsize&pli=3D1
2009/8/27 Vincent Rivi=E8re <vincent.riviere@freesb= ee.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 t= hrough 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=3D1.4&content-type=3Dtext/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 =3D Fcntl (fd, &xattr, FSTAT);
...
st->st_blocks =3D (off_t) (((off_t) xattr.st_blocks
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * (off_t) xattr.st_blksize= ) >> 9);
st->st_blksize =3D xattr.st_blksize;

We can see that most of the values are directly copied from the xattr struc= ture 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 =3D 65535. It is 128 actually times 512 = bytes. And if I compile a small program calling stat() and showing the valu= e 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 se= ems 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 fi= x some bogus software assuming a 512 bytes block size ? It is certainly a b= ad idea, because it is not always the case in the read world.

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

--
Vincent Rivi=E8re



--001636ed667af8aa4c04721c5e50--