View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001071 | Double Commander | Default | public | 2015-04-07 16:56 | 2020-06-19 21:52 |
Reporter | hans70 | Assigned To | Alexx2000 | ||
Priority | normal | Severity | crash | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Projection | none | ETA | none | ||
Platform | Linux | OS | Debian GNU Linux | OS Version | 8.0 |
Product Version | 0.6.1 | Product Build | 5936 | ||
Target Version | 0.7.6 | Fixed in Version | 0.7.6 | ||
Summary | 0001071: cm_LeftOpenDrives fails on fuse mounts (tested with sshfs and smbnetfs) | ||||
Description | When mounting filesystems (at least sshfs and smbnetfs) via "fuse" on Linux which are configured in /etc/fstab. Doublecommander fails to mount them via cm_LeftOpenDrives or even crashes (when pressing cancel in error-dialog). Using the prebuild binaries of doublecmd from double commanders homepage. | ||||
Steps To Reproduce | On Linux you can also use sshfs to access directories on remote servers (and for testing on local linux-box). 1.) install "sshd"on your local linux box. In your shell do "ssh localhost" to verify correct operating of sshd and login. 2.) install fuse and sshfs like: "apt-get install sshfs" 3.) create directory /mnt/fuse-test 4.) chmod 777 /mnt/fuse-test 5.*) edit "/etc/fstab" and add following line: localhost:/ /mnt/fuse-test fuse.sshfs noauto,users 0 0 6.) try mounting this in shell with: mount /mnt/fuse-test It should show the / of you linux box 7.) (IMPORTANT!) "umount /mnt/fuse-test" (as root in a shell) 8.) now try mounting this with doublecmd via function cm_LeftOpenDrives / cm_RigthOpenDrives Result: a dialog popup with: -- Error: Invalid device file name localhost:/ Please send a Bugreport .........(and so on) -- * Remark to 5.) sshfs also allows username at mountpath like: user@localhost:/ ... this also produces the error. backtrace: --------------- 07-04-2015, 14:34:54 --------------- | DC v0.6.1 beta Rev. 5936 -- i386-Linux-gtk2 | Debian 8.0 -- GTK 2.24.25 Unhandled exception: Exception: Invalid device file name: localhost:/ Stack trace: $0858F88B line 186, column 69 of platform/unix/uudisks.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $081E65AE line 531, column 17 of platform/unix/umyunix.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $081E272F line 857, column 15 of platform/uOSUtils.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $081D303D line 5348, column 6 of fmain.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $081D2D4D line 5305, column 3 of fmain.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $084B037F line 492, column 5 of udriveslist.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $084B032E line 484, column 5 of udriveslist.pas in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $0823FC70 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $082400FD in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $08135476 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $08232B67 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $083CE574 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $083B5909 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $082F60B6 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $08304AC1 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $083042B1 in /usr/local/doublecmd_0.6.1_gtk2_i386/doublecmd $B72E2C2C in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 | ||||
Additional Information | More and pretty formated information on the forum: http://doublecmd.sourceforge.net/forum/viewtopic.php?f=6&t=2642 This problem could also be present in MacOS and BSD and for shure on 64bit Linux. but I did not test this. This problem occurred also in version 5.10 and 5.11 gtk2 i386 of doublecommander with prebuild binaries. | ||||
Tags | No tags attached. | ||||
Fixed in Revision | 7144,7154 | ||||
Operating system | Linux | ||||
Widgetset | GTK2 | ||||
Architecture | 32-bit | ||||
|
The problem still occures in version v0.6.6 beta build 6327, but maybe I found a solution to fix it.: * In file "platform/unix/umyunix.pas" you work with the systems fstab (/etc/fstab). * From "/etc/fstab" you seem to get infos for some mountable devices. * Informations about mountable devices are stored in record "TFSTab". * Function "MountDrive" then trys to mount via several methods (udiskctl, udisks and pmount) ==> now the solution: * in function "MountDrive" do an additional system call "mount <MOUNT_POINT>" - this will most probably work on all unix boxes (BSD, Unix, Linux,...) - password request will be done by desktop environment automagically - mount directory will allready exist, because fstab consits of static entries - umount already works - this call could fail, if the user has not the proper rights, but most probably it will succeed. # Example for system call: # entry in /etc/fstab: user@192.168.1.2:/share/ /media/remote-share fuse.sshfs noauto,defaults 0 0 # then the appropriate system call would be: mount /media/remote-share |
|
>>> - password request will be done by desktop environment automagically I am not sure that this works in all DE. If this does not work somewhere then DC will hang, because mount will wait password in console. |
|
Hi , i got a fix ... partially ... @Alexx2000 thanks for your reply, this IS correct ... nevertheless I finaly set up an development environment and run a few tests with the 0.6.6 beta branch from svn. looks like there is an typo in umyunix.pas: in function MountDrive the line Result := fpSystemStatus('mount ' + Drive^.DeviceId) = 0; should state: Result := fpSystemStatus('mount ' + Drive^.Path) = 0; then mounting is working for sshfs. yeah!! But as you stated if there is a filesystem which requires a password (like encfs) doublecommander "freezes" because it is waiting for a password. :( By the way I am not using any DesktopEnvironment at all just plain fvwm2 window manager. Regards |
|
for fix see remark above. Is it possible to have an Configure-Option at Preferences where the user could put a shell-skript (or programm) which does proper mounting in every case for the user? There are different mount wrappers than udisks (which sucks by the way) for mounting it is possible to use: * mount and fusermount * udisks (version 1) * udisksctl (version2) * pmount * mount-gtk * udevil (which is a replacement for udisks) * own shell skripts It would be impossible to write code for all variants of mounting and using that program which the user prefers. |
|
Maybe fixed. Please try with latest DC 0.8 builds. >>>Is it possible to have an Configure-Option at Preferences where the user could put a shell-skript (or programm) which does proper mounting in every case for the user? Theoretically, yes, it can be done. |
|
Hi Alexx200, thanks for taking care on this bug, and sorry for the late reply. I tested with nightly build from 2016.Okt.23 rev7166, the bug seems to be fixed. :) |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-04-07 16:56 | hans70 | New Issue | |
2015-11-21 09:19 | hans70 | Note Added: 0001599 | |
2015-12-08 00:02 | Alexx2000 | Relationship added | related to 0001231 |
2015-12-15 13:45 | Alexx2000 | Note Added: 0001612 | |
2015-12-15 13:45 | Alexx2000 | Status | new => acknowledged |
2015-12-15 13:46 | Alexx2000 | Note Edited: 0001612 | |
2016-01-18 02:53 | hans70 | Note Added: 0001639 | |
2016-01-18 03:02 | hans70 | Note Added: 0001640 | |
2016-10-15 11:36 | Alexx2000 | Fixed in Revision | => 7144 |
2016-10-15 11:36 | Alexx2000 | Note Added: 0001961 | |
2016-10-15 11:36 | Alexx2000 | Status | acknowledged => resolved |
2016-10-15 11:36 | Alexx2000 | Resolution | open => fixed |
2016-10-15 11:36 | Alexx2000 | Assigned To | => Alexx2000 |
2016-10-15 11:37 | Alexx2000 | Relationship added | related to 0001555 |
2016-10-15 11:40 | Alexx2000 | Note Edited: 0001961 | |
2016-10-15 18:03 | Alexx2000 | Target Version | => 0.7.6 |
2016-10-21 20:37 | Alexx2000 | Fixed in Revision | 7144 => 7144,7154 |
2016-10-21 20:37 | Alexx2000 | Fixed in Version | => 0.7.6 |
2016-10-23 14:26 | hans70 | Note Added: 0001966 | |
2020-06-19 21:52 | Alexx2000 | Status | resolved => closed |