Cute idea, maybe. But very inconsistent with the size in blocks (reported by
ls -dls dir).
Is there a particular reason for this, or is it one of those just for the heck
of it things?
Granted that it isn't necessarily _wrong_. I just checked SUSv3 for stat() and
sys/stat.h,
and it appears that st_size is only well-defined for regular files and
symlinks. So I suppose
it could be (a) undefined, or (b) whatever is deemed to be useful, for
directories,
device files, etc.
This is of course inconsistent with the behavior on other filesystems. On UFS
(a bit
of a special case perhaps in that it still allows read(2) on a directory, for
compatibility),
the st_size seems to reflect the actual number of bytes used by the
implementation to
hold the directory's current contents. That may well also be the case for
tmpfs, but from
user-land, one can't tell since it (reasonably enough) disallows read(2) on
directories.
Haven't checked any other filesystems. Don't have anything else (pcfs, hsfs,
udfs, ...)
mounted at the moment to check.
(other stuff: ISTR that devices on Solaris will give a size if applicable,
but for
non LF-aware 32-bit, that may be capped at MAXOFF32_T rather than returning an
error;
I think maybe for pipes, one sees the number of bytes available to be read.
None of
which is portable or should necessarily be depended on...)
Cool ideas are fine, but IMO, if one does wish to make something nominally
undefined
have some particular behavior, I wonder why one wouldn't at least try for
consistency...
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
