Roland McGrath <[EMAIL PROTECTED]> writes:
>> Roland McGrath <[EMAIL PROTECTED]> writes:
>>
>> > It is a nice feature that st_size is useful on disks in the Hurd, even
>> > though it's useless on Unix. For st_blocks, it makes less sense per se
>> > because it's not using space on the containing filesystem. Arguably it
>> > should just leave it alone so it's whatever is actually being consumed on
>> > the underlying filesystem, which will normally be zero.
>>
>> Does this mean I can commit the patch?
>>
>> If not, what do you suggest to do?
>
> Have you tried what I suggested above? i.e., don't modify st_blocks from
> what trivfs starts with.
That worked fine for me. I have included a patch to do this with this
email.
Thanks,
Marco
2005-01-07 Marco Gerards <[EMAIL PROTECTED]>
* storeio.c (trivfs_modify_stat): Don't initialize st_blocks.
Index: storeio.c
===================================================================
RCS file: /cvsroot/hurd/hurd/storeio/storeio.c,v
retrieving revision 1.24
diff -u -p -r1.24 storeio.c
--- storeio.c 22 Jun 2002 21:13:26 -0000 1.24
+++ storeio.c 7 Jan 2005 12:46:49 -0000
@@ -299,8 +299,6 @@ trivfs_modify_stat (struct trivfs_protid
st->st_blksize = store->block_size;
st->st_size = size;
- st->st_blocks = size / 512;
-
st->st_mode |= ((dev->inhibit_cache || store->block_size == 1)
? S_IFCHR : S_IFBLK);
}
@@ -309,7 +307,6 @@ trivfs_modify_stat (struct trivfs_protid
{
st->st_blksize = 0;
st->st_size = 0;
- st->st_blocks = 0;
st->st_mode |= dev->inhibit_cache ? S_IFCHR : S_IFBLK;
}
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
