[openbeosstorage] Re: BNode:set_fd and other things

> I noticed, that the BNode::set_fd() implementation doesn't return a
> value. 
 
Oops... ;-)

[...]

> (Just to prevent, that future changes to set_fd()'s implementation break
> BFile: Currently it is assumed, that the supplied file descriptor is not
> closed in case set_fd() returns a value != B_OK.)

Okay, thanks for the heads up. :-)

> I wonder, if BDirectory::fDir/fDirFd will be needed at all. At least until
> now I see no reason, why the file descriptor used by BDirectory should be
> a different one than that of BNode. Perhaps I'm missing something, but
> I will see as soon as the test suite is done and the class is implemented.
> However, friend classes will use get_fd() anyway.

Yes, I know what you mean. I haven't done any tests to figure out whether or 
not it's necessary.

I say try to implement it using BNode::get_fd(). Make sure none of the public 
BNode functions (i.e. reading an attribute value with BNode::ReadAttr() or 
something like that) disrupt the internal directory pointer or anything else 
BDirectory would use that would be associated with the file descriptor. If 
everything looks okay, we'll just go with that. If you find something that 
doesn't work right, we can just switch back to using BDirectory::fDirFd. 

> Just to be sure: StorageKit::FileDescriptor will be the (only) type we'll
> use in the SK classes. Correct?

Maybe :-). See my "Kernel Interface Typedefs" message. I'm not sure I see what 
we gain by getting rid of the other typedefs. It's admittedly an option now, 
though, since we can use FileDescriptors everywhere.

> And StorageKit::Dir will disappear and directory file descriptors will be
> treated as any other file descriptor. Also correct?

Yes. I'm working on making that happen (sorry it's taking so long).

-Tyler

Other related posts: