> 2005-01-07 Marco Gerards <[EMAIL PROTECTED]>
>
> * storeio.c (trivfs_modify_stat): Don't initialize st_blocks.
Ok by me.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
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
> 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 i
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 i
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> For what it is worth, on OpenBSD st_nblocks is 0 for /dev/zero, so I
> think this patch is correct and it won't break any existing program.
I am running GNU/Hurd using this patch now and everything seems fine to
me so far.
Anyway, if everything is
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 under
For what it is worth, on OpenBSD st_nblocks is 0 for /dev/zero, so I
think this patch is correct and it won't break any existing program.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Hi,
There is a problem with storeio. Ognyan reported this on savannah
already:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=10440
The problem is that the size of /dev is huge (which is reported by `ls
-l' as total). This is caused by /dev/zero:
9007199254740992 crw-rw-rw- 1 root ro
