GNOME Bugzilla – Bug 522424
SSH synchronisation: does not unmount the filesystem after synching
Last modified: 2009-04-23 02:14:01 UTC
Please describe the problem: Tomboy does not seem to unmount the sshfs mount after syncrhonisation is completed. This means that subsequent synch attempts fail with a "permission denied" error--a misleading error that appears to come from the fact that sshfs exits with 'permission denied' if attempting to mount an sshfs filesystem on top of another sshfs filesystem. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Hmm, sometimes I get a different message, complaining that the mount point is non-empty. I don't know why I sometimes get one error and sometimes another.
Can you reproduce this and attach a copy of your ~/.tomboy.log file? The SSHFS mount is supposed to be unmounted after 5 minutes, not immediately after a sync. Sync should notice that it's already mounted and not try to mount again. I'm hoping your .tomboy.log file will have some more helpful output. Actually, looking at your other report related to timeouts, this may be related to bug #509382.
Created attachment 107299 [details] tomboy log Let me know if you want any more info.
This may be related to the timeouts. Do you still get the problem if you change that gconf setting I mentioned in the other bug so that you don't have timeouts?
I've actually added the DNS entry for the host we are SSH'ing to to /etc/hosts so that sshfs completes within about two seconds. This is actually someone else's system, I am just reporting the bugs that I found while setting this up. If you think that my tweak won't have the same effect as increasing the timeout then say so and I'll revert taht change and increase the timeout instead.
Basically I'm just wondering if you have more success when you have no timeouts. Whether you do that by tweaking /etc/hosts or by increasing the Tomboy max timeout shouldn't make a difference.
I'm having the same problem and its clearly not a timeout issue. The core problem is that the IsMounted() function in FuseSyncServiceAddin.cs is completely wrong.. Tthe first part of the line returned by mount is the user@host:path and not the executable name... And this is with kernel 2.6.2[34], sshfs 1.9 and fuse 2.7. In the future, wouldnt it be easier to port the whole thing to GIO and not have to bother with fuse at all? Anyways, I'm attaching a patch that fixes the problem.
Created attachment 108750 [details] [review] only check the path
Still getting this on 0.10.1 on Ubuntu Hardy.
A few workarounds with more or less success mentioned downstream (https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/152978): fusermount -u ~/.tomboy/sync-sshfs rm -f ~/.tomboy/sync-sshfs/lock
Btw, even with my patch, it seems to leave lock files lying around all the time... We need GIO...
Just committed a patch based on Olivier's in r2007. Once some Hardy users test it I'll resolve this bug. Thanks for the catch, and sorry for the delay in fixing it. Olivier: I agree that we should ditch fuse for GIO, but I'm not sure that would fix the lock file situation. We create those files to prevent simultaneous syncs from multiple clients, and if they're still around then we are not cleaning them up properly. But perhaps if we're better about managing our mounts it will help the lock file stuff as a side-effect.
*** Bug 533565 has been marked as a duplicate of this bug. ***
I'll be putting this in an 0.10.2 release, probably Monday, as it's going to affect a lot of distros besides Hardy.
In the mean time, if you are affected by this, manually mount your desired share somewhere, and then use Tomboy's "Local Folder" sync service and point to the place you mounted it
This bug is still present in 0.10.2. I see the patch attachment has been marked as obsolete, but the bug is still marked NEW. What is the current status of this issue?
(In reply to comment #16) > This bug is still present in 0.10.2. > > I see the patch attachment has been marked as obsolete, but the bug is still > marked NEW. What is the current status of this issue? Partly fixed, waiting on developer time to figure the rest out. Sorry.
Note to self: bug #535279 is probably a dupe.
Okay, this bug has been fixed a long time. Bug #535279 is a different problem related to lock files that I will be fixing, and anybody still having problems is probably experiencing that.