userlandfs does not work correctly if installed in home (instead of system)

[ttcoder]

While testing further I ended up with userland-fs installed in home/config/packages (instead of system/packages), and things don't work as expected. Symptoms:

• a /dev/disk/atapi/3/master/0 device shows up as soon as the audio CD is inserted (not waiting for a mount command to be issued), and even with auto-mounting disabled in Tracker preferences; one can see it pop up in real time by leaving DriveSetup open when inserting the CD.
• when the actual mount command is issued in Terminal, it returns "mount: No such file or directory":

Executing userlandfs line <mkdir -p /audiocd ; mount -t userlandfs -p cdda /dev/disk/atapi/3/master/raw /audiocd>
mount: No such file or directory

Took me a while to understand the problem was due to the package being in home, because that status_t (no such file) is the same one returned when you mistype the filesystem name and invoke e.g. -t userlandfs -p cddda.

Suggestions..

• improve error handling, to distinguish those 2 error cases
• look into why userlandfs wants to be installed in system
• or if it's the case that some packages simply cannot live in home at all, extend the hpkg properties/syntax of dependancies to manage this ; use-case: I have declared a depends: userland-fs dependancy in my CD-ripping app, which means if that application package is installed in system then userlandfs is correctly installed in system, but if the application is installed in home then userlandfs is downloaded and installed in home too.

[ttcoder]

Disregard the first symptom, it seems to be normal as it occurs the same way now that I've moved the userlandfs package back to system. I can confirm the second symptom however: the package needs to live in system for mount to work, indeed I'm able to rip CDs again now.

[pulkomandy]

The first "symptom" is the partition being published by the "session" partition manager (which allows reading multi-sessions CDs and mixed contents (audio/data) ones by publishing the relevant part as partitions to the file systems. It's possible to blacklist session if you really want to avoid this, but it should not be a problem to leave it around.

I suspect the problem is failure to find and run the userlandfs_server because its path is hardcoded to /system (see src/add-ons/kernel/file_systems/userlandfs/kernel_add_on/FilesystemInitializer.cpp:69). This probably should use BPathFinder to look for the server in all the "server" directories available or use a package-relative path. Since the executable for the server is not found, the error is "no such file or directory", which makes sense when looking at it this way.

[pulkomandy]

Unfortunately BPathFinder and find_path can't be used directly because this is kernel-side code. Until this is fixed I think it's possible to run the userlandfs server manually as explained here: ​http://lists.ports.haiku-files.org/pipermail/haikuports-devs-ports.haiku-files.org/2012-June/003271.html

[bonefish]

Since userlandfs has a kernel module component, it has to be installed in system anyway. That it can be installed in home in the first place is due to a missing feature in the package management system. A respective package attribute needs to be introduced, so that the package managers and daemon know of the restriction.

[ttcoder]

Hi Ingo, not sure how that factors into the discussion, but FWIW we are using a custom build of the kernel add-on overriding the one from the haiku userland_fs package, with ​this line

		"/system/servers/userlandfs_server",

modified to point in home instead, and that's where we got successful, in my testing's and Dane's; we're going to production with that.. Agreed it would be interesting to add a flag to the hpkg files though, to allow to force them to go to system (there is a "system package" element in the .PackageInfo grammar but is it related?). Sometimes I install a package in home yet I don't want all its dependancies to end up in home as well, not as tidy.