On 2010-01-19 at 03:41:06 [+0100], mmlr@xxxxxxxx wrote: > Author: mmlr > Date: 2010-01-19 03:41:06 +0100 (Tue, 19 Jan 2010) New Revision: 35152 > Changeset: http://dev.haiku-os.org/changeset/35152/haiku > > Modified: > haiku/trunk/src/add-ons/kernel/file_systems/netfs/shared/FSObject.cpp > Log: > The default for deleteWhenUnreferenced changed between the Referencable > of the old userlandfs and the BReferenceable now in use by netfs. So > better explicitly set that to avoid nasty surprises (like crashes left > and right). Thanks a lot. I actually made a mental note to check up on BReferenceable changes and even did, but I just checked the meaning of the parameter and forgot about the default value. :-D With these changes, I am able to mount shares. I actually thought that it wouldn't work yet, because of stat versus beos_stat, but it appears, Ingo already took care of that for BeOS R5 file systems in UserlandFS. At least it doesn't seem to give problems. I started to port netfs to the new file system API, but have not gotten very far yet. Looking at the changes between src/tests/add-ons/kernel/file_systems/userlandfs/src/test/r5/reiserfs and src/add-ons/kernel/file_systems/reiserfs is quite enlightning, but it seems that I still lack the necessary overview to make the correct decisions everywhere. Michael, what are your experiences so far, does netfs work reliably for you? For me, it seems to be the case so far. We could make an OptionalPackage for the various components. NetFSServer and AuthenticationServer could be renamed to netfs_server and authentication_server and be placed in /system/servers. netfs_config could go into /system/bin (although I have no idea what it is really for). A dependency to the UserlandFS OptionalPackage could be added. I am also wondering if the code should be pulled apart, or if it should all stay in the netfs file_system add-on folder. On the one hand it's nice to have it all in one place, but most parts of the code are misplaced looking from another perspective. Opinions? Best regards, -Stephan