-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support subdir mounts #399
Comments
should now see subdir mounts which are not on a block device
In 0f4ed8b subdir mounts on a non-block device (eg a network) should be shown. Note that this commit is currently in the under-development hand branch, which is not yet recommended for testing. But you can run it with a test config to see if the mounts are listed, or you can wait until the hand branch is advertised for testing. |
See #478 |
Mounted smb://localhost/public
Both mounts have the same major:minor numbers! wow! OK, to summarize:
|
Thanks for testing.
This is normal. If you want this detected you will need to do it in the handler - your handler can open an existing mount point instead of doing a new mount.
SpaceFM may be having trouble seeing that the added device is the one that was just mounted. I'll take a look, but you can also manually open the mount point after a successful mount by running 'spacefm -t %a', or in your case you may want to pass a custom dir name to udevil so you know where it's mounted. Or udevil also replies with that info to stdout which you can parse.
Very strange, smb must be handling this internally. SpaceFM will only list one device in that case. Overall this sounds to be just about working within current specs and any greater fine-tuning for this fs should be done in the handler. But I'll take a look at why it may not be auto-opening the cifs mount. It's probably because you're opening it with "smb://..." and the URL in mtab is "//..." Just for future reference, if SpaceFM can't correlate a device added with the mount just performed, it won't auto-open. |
I propose this: |
I will leave this open, but it will probably require someone to do some testing with smb specifically while working on the code. It's not something I normally use. I will take a brief look at a few of the above conditions to see if I can improve them generally. |
If anyone wants to look at details, here are the two functions that primarily control what devices you see and how mountinfo is parsed... This parses mountinfo: parse_mounts() If a non-block device is found (no udev info), this function fills in the volume info based on the mount alone, and determines visibility: vfs_volume_read_by_mount() A separate function handles block devices, not relevant here. Ordering hierarchy of subdir mounts would likely be a significant function rewrite, and that's a complex function as it is. Not sure the likelihood of multiple subdir mounts with the same root would warrant such investment. Because no udev events can be watched for non-block devices, SpaceFM watches the mountinfo file for changes and parses it again. Please don't anyone invest in a large rewrite without consultation, because that function affects a lot. Just changing it for one specific area will require extensive testing of all its uses. However, if you find minor issues these may be addressed. |
Show if is protocol handler fs_type Show if type not in: devpts proc fusectl pstore sysfs tmpfs devtmpfs Must be user-readable mount point
Looking this over, I can see why smb mounts are not automatically opened. This will be the case for many protocols, when the added device is not necessarily correlated with the protocol being mounted. Rather than hardcode hacks for this, due to the wide variation, I think it's best for handlers to open the mount point on successful mount. This has been noted in the manual. Multiple subdir mounts under smb is not perfectly detected as you know. No immediate change here, and again this is mostly something for the handler to check - when mounting the same resource just open the mount point, etc. |
spacefm -t "%a" does not work, it tries to open new window and immediately closes. |
Actually that command is by socket - it sounds like a misconfiguration where the socket is unreachable/unwritable. That should not open a new window unless socket communication is failing. The window closing sounds like a crash. By socket command you can use |
When you mount some resource not at it's root, but at subdir, spacefm does not see the mount.
i.e. smb://server/share/subdir
The text was updated successfully, but these errors were encountered: