Skip to content
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

Open
Vladimir-csp opened this issue Dec 12, 2013 · 10 comments
Open

support subdir mounts #399

Vladimir-csp opened this issue Dec 12, 2013 · 10 comments

Comments

@Vladimir-csp
Copy link

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

//server/share/subdir on /media/smb-server-share-subdir type cifs (...)
IgnorantGuru pushed a commit that referenced this issue Feb 23, 2014
should now see subdir mounts which are not on a block device
@IgnorantGuru IgnorantGuru modified the milestones: near, far Feb 23, 2014
@IgnorantGuru
Copy link
Owner

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.

IgnorantGuru pushed a commit that referenced this issue Mar 20, 2014
@IgnorantGuru IgnorantGuru modified the milestones: 0.9.5, near Mar 30, 2014
@IgnorantGuru IgnorantGuru modified the milestones: hand, 0.9.5 Feb 25, 2015
@IgnorantGuru
Copy link
Owner

See #478

@Vladimir-csp
Copy link
Author

Mounted smb://localhost/public
It mounted OK, but did not open.
Then mounted smb://localhost/public/links It mounted again, instead of opening existing mount (#398), and did not open mountpoint.
Also new subdir mountpoint was not listed in devices.

105 19 0:36 / /media/smb-localhost-public rw,nosuid,nodev,noexec,relatime shared:89 - cifs //localhost/public rw,vers=1.0,cache=strict,domain=MINDFLASH4,uid=1000,noforceuid,gid=100,noforcegid,addr=0000:0000:0000:0000:0000:0000:0000:0001,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1
108 19 0:36 /links /media/smb-localhost-public-links rw,nosuid,nodev,noexec,relatime shared:92 - cifs //localhost/public/links rw,vers=1.0,cache=strict,domain=MINDFLASH4,uid=1000,noforceuid,gid=100,noforcegid,addr=0000:0000:0000:0000:0000:0000:0000:0001,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1

Both mounts have the same major:minor numbers! wow!
When I unmounted first mount, second did no appear in list.
When I unmounted everything and then mounted only subdir, it appeared in devices list.
Then I mounted smb://localhost/public, nothing changed
Then I unmounted smb://localhost/public/links, smb://localhost/public appeared in list!

OK, to summarize:

  • entering URL pointing to subdir of already mounted resource results in second mount.
  • smb share does not open after mount
  • two mounts of same smb resource have same major:minor, no way to work around that
  • when resource root is mounted first, and resource subdir is mounted second, if you unmount resource root, resource subdir does not appear in the list. When you mount and unmount the other way around, it works.

@IgnorantGuru
Copy link
Owner

Thanks for testing.

entering URL pointing to subdir of already mounted resource results in second mount.

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.

smb share does not open after 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.

two mounts of same smb resource have same major:minor, no way to work around that

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.

@Vladimir-csp
Copy link
Author

I propose this:
If there are several mounts with same major:minor, list the one higher in hierarchy. When one of them is unmounted, update the list (which is not happening now in half of the cases).

@IgnorantGuru
Copy link
Owner

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.

@IgnorantGuru IgnorantGuru reopened this Mar 10, 2015
@IgnorantGuru
Copy link
Owner

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.

IgnorantGuru pushed a commit that referenced this issue Mar 11, 2015
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
@IgnorantGuru
Copy link
Owner

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.

@Vladimir-csp
Copy link
Author

spacefm -t "%a" does not work, it tries to open new window and immediately closes.
What is the best way to do it by socket?

@IgnorantGuru
Copy link
Owner

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
spacefm -s set new_tab "%a"

@IgnorantGuru IgnorantGuru modified the milestones: limbo, hand Apr 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants