> "Richard L. Hamilton" <rlha...@smart.net> wrote: > > > 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. > > You could also return 0 for st_size for all > directories and would still be > POSIX compliant. > > > Jörg >
Yes, some do IIRC (certainly for empty directories, maybe always; I forget what OS I saw that on). Heck, "undefined" means it wouldn't be _wrong_ to return a random number. Even a _negative_ number wouldn't necessarily be wrong (although it would be a new low in rudeness, perhaps). I did find the earlier discussion on the subject (someone e-mailed me that there had been such). It seemed to conclude that some apps are statically linked with old scandir() code that (incorrectly) assumed that the number of directory entries could be estimated as st_size/24; and worse, that some such apps might be seeing the small st_size that zfs offers via NFS, so they might not even be something that could be fixed on Solaris at all. But I didn't see anything in the discussion that suggested that this was going to be changed. Nor did I see a compelling argument for leaving it the way it is, either. In the face of "undefined", all arguments end up as pragmatism rather than principle, IMO. Maybe it's not a bad thing to go and break incorrect code. But if that code has worked for a long time (maybe long enough for the source to have been lost), I don't know that it's helpful to just remind everyone that st_size is only defined for certain types of objects, and directories aren't one of them. (Now if one wanted to write something to break code depending on 32-bit time_t _now_ rather than waiting for 2038, that might be a good deed in terms of breaking things. But I'll be 80 then (if I'm still alive), and I probably won't care.) -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
