[openbeos] Re: Incorrect File Sizes

  • From: argent@xxxxxxxxxxxxxxxxxx
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 4 Dec 2002 14:53:28 -0500

on Wed, Dec 04, 2002 at 05:21:49PM +0100, Axel Dorfler was heard to have 
remarked:
> "Scott MacMaster" <zqxh@xxxxxxx> wrote:
> > I just noticed that Be doesn't correctly calculate file sizes.  I'm 
> > not sure
> > of the details but I think the bug is probably in the BFS rather then
> > tracker.  I wonder if this has been dealt with in OpenBFS?
> > 
> > The bug is simply, the size of attributes aren't added to the file 
> > size.
> 
> That's not a bug, that's wanted. As a user you would be very confused 
> if the file sizes would always change, or just be different on BeOS, or 
> when you copy it to another volume, etc.
> You can't do that, it would make a horrible user experience (hey, even 
> Windows doesn't do this for NTFS).
> No, it would be very nice to know how much space a file needs on disk, 
> including the attributes - unfortunately, BFS don't have a single 
> counter for that, so that you'd need to iterate over all attributes to 
> calculate their size. It would be very simple to do, but I want to have 
> that functionality both in Tracker and BFS, but optionally, not instead 
> of the real file size.

Does BFS (internally) keep track of the extra space used by
attributes (at least the block count)?  Also, IIRC (classic) BFS uses
a block for each attribute after the "close space" (in the inode) has
been used.  Is that the case?  Is it still the case in OpenBeOS?

I'm away from the source at the moment, plus I haven't been reading up
on it.  :-)

Anyway, could we add another (two) C functions:
status_t fs_size_attr_dir(const char* path);
status_t fs_fsize_attr_dir(int fd);

These would parallel the fs_open_attr_dir functions, but return
blocksize*attr_blocks_used for a file.

[Are we still using status_t for these functions?  I don't know if
size_t would be a better measure here... How bid is are status_t and
size_t?]

Anyway, *great* job on OpenBFS!  I'm impressed with your progress.

-- 
Evan Knop <argent@xxxxxxxxxxx>      http://lore.dartmouth.edu/~argent/

It's great to be smart 'cause then you know stuff.

Other related posts: