Version: (using KDE 4.2.0) OS: Linux Installed from: Gentoo Packages Hello, I want to browse my nfs shares with dolphin/nfs kpart. I see my shared folders from /etc/exports if if go to nfs://hostname.domainname:2049. But im am not able to follow the links if there is more than one level to the path, e.g. I have /home/user/Archives/ *(rw,insecure,no_root_squash,sync) in my /etc/exports/, So I see "home⁄user⁄Archives" in dolphin. But the slashes are wrong, it's "⁄" instead of "/" hence I cannot follow that link. This behavior is always reproducible for me.
This is true also for me on KDE 4.2.2 (kdemod from arch linux). I see a slash that dangles to the right (⁄) more than the normal one /. Big problem is that if i substiture the strange slash with the normal one dolphin says that the folder does not exist...
(In reply to comment #1) > This is true also for me on KDE 4.2.2 (kdemod from arch linux). > > I see a slash that dangles to the right (⁄) more than the normal one /. > Big problem is that if i substiture the strange slash with the normal one > dolphin says that the folder does not exist... It seems (from kcharselect) that this slash is called Fraction Slash and is UTF-8: 0xE2 0x81 0x84
*** Bug 184999 has been marked as a duplicate of this bug. ***
Still valid for 4.3 Beta1
Still valid for 4.3 beta 2 on kubuntu karmic amd64.
and also in openSUSE 11.2 Milestone 2 with kde 4.3 B2
Still valid for KDE 4.3 (final)
Still valid for kde 4.3.1
Actually, this bug is still valid for kde 4.3.3 ;-)
*** Bug 193918 has been marked as a duplicate of this bug. ***
Same issue here with 4.3.2 on Mandriva 2010. Let me know if further details are required. Cheers, Alan.
KDE 4.4 RC1. (Kubuntu packages). It's still ⁄ instead of / and the NFS shares are not accessible.
Still there in KDE 4.4.62svn1084462 openSUSE 11.2 It could be a bug in kio_nfs but I cannot find this character anywhere in kdebase-runtime sources. Btw it appears in konqueror too.
Also in KDE 4.4RC3, so we can assume it will be in 4.4 too (expected later today) I'm not a programmer, but I also searched the source (you never know). I didn't find the character either.
According to KCharSelect, the character is fraction slash: It can be represented in this formats too: UTF-8: 0xE2 0x81 0x84 UTF-16: 0x2044 C octal escaped UTF-8: \342\201\204 Desítková XML entita: ⁄ So maybe someone or me could search the source for this?
Has anyone checked to see if this character is what's actually being reported by NFS? If it's not part of the client then it must be part of the server. I'm not sure how one might go about finding this out other than either to hand code a dummy NFS debugging client (that describes in computer-readable format what's going on in the background) or access NFS manually using telnet or somesuch. I've done this with HTTP (GET /path/file.html HTTP/1.1) and FTP but I think NFS might be a bit too complicated to do manually.
I have captured communication between NFS server and Dolphin (kio_nfs) in Wireshark. All slashes in packets was Slash 0x2f, from server also from client. Paths was send in correct format. So I think that there must be something really nasty in kio_nfs.
Persist in KDE SC 4.5.0... hopeless.
"Fraction slash" is used by KIO when filenames contain a '/'. This sounds like a bug in kio_nfs then, which returns paths instead of filenames -- probably in UDS_NAME. To be investigated further.
OK I can't get kio_nfs to work at all here, in order to debug this. I have a mount point /k on host obelix, and I can mount it from the command line: /etc/fstab says: obelix:/k /k/nfsob nfs defaults,noauto,user 0 0 and mount says: obelix:/k on /k/nfsob type nfs (rw,user=dfaure,addr=192.168.0.1) But if I open nfs://obelix it shows nothing, and nfs://obelix/k says "does not exist". Am I testing this correctly? Surely you guys see shares at least, to get to the 'fraction slash' bug. NFSProtocol::openConnection: NFS::openConnection for "obelix" NFSProtocol::openConnection: hostname is - "Asterix" - NFSProtocol::checkForError: rpc error: 9 Alex, any input?
For some reason to see shares on remote machine, there must be a option "insecure" in /etc/exportfs. This is my record in exportfs: mnt/data/music 10.9.0.0/24(rw,sync,subtree_check,insecure) Descriptions for this option is: "The insecure option in this entry also allows clients with NFS implementations that don't use a reserved port for NFS." I guess that kio_nfs uses unprivileged ports > 1024, because it runs under user.
Created attachment 52967 [details] Dolphin with bad fractions slashes in paths To see shares list, there must be a option "insecure" in exportfs.
So, any progress?
Created attachment 54427 [details] patch to fix wrong eoncoding of "/" This patch seems to fix this issue. The paths originally were stored using KIO::encodeFileName() (which converts / to 2f) but never decoded using KIO::decodeFileName(). I have tried it first by using KIO::decodeFileName(). This didn't work however, so I tried to remove the encode completely. This indeed seems to fix this problem. Is this safe to commit?
Thanks for the patch, I'm reassigning this to kio/nfs as I cannot judge whether the patch is OK.
Created attachment 54435 [details] new patch using 2f character for root folders OK... Now I've understood the problem. The reason for using '⁄' instead of '/' is to prevent the user from navigating up the root path. Example: If you have a share, say "10.10.10.1/mnt/data/share1" containing folders named "foo/bar" it will appear in dolphin this way: nfs://10.10.10.1/mnt⁄data⁄share1/foo/bar (notice the ⁄ instead of / in mnt⁄data⁄share1 and the regular / afterwards). This makes the root path "mnt⁄data⁄share1" appear as a single folder and prevents the user to navigate to /mnt/data as this won't be accessible either. So this kinda would improve usability here. However, this comes at a cost. When using this notation the user cannot input "nfs://10.10.10.1/mnt/data/share1/foo" any more into the address field, but is forced to navigate to it by clicking the icons (or input the ⁄-character somehow which usually isn't present on a keyboard). Attached you find a patch that fixes the ioslave to be used this way by using the correct combination of KIO::encodeFileName() and KIO::decodeFileName(). Currently this works only for browsing using the ioslave. Opening documents using other applications does not work as there seem to be more places having problems with '⁄'. Anyways, in my opinion the first patch is the one that should be applied as it enables the user to input the path manually into the address field. (and it works also for opening files with other apps)
After spending nearly the whole weekend debugging this ioslave I'm pretty confident that I know what I'm doing. So I'm going to commit this along with a hand full of other bugfixes for this slave. I'm on a good way to make nfs:// usable for 4.6 again.
SVN commit 1205839 by mzanetti: Don't use use fraction slash for nfs paths. This keeps the possibility to manually input the path and fixes BUG: 184997 M +2 -2 kio_nfs.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1205839
Oh, that sounds great. I'am looking forward to KDE 4.6.
That's a really special present for christmas. Thank you very much. This is a long waithed feature back in KDE.
Hi, does it work now? I have kde version 4.7 with Gentoo. When I click on an NFS share, the following message: The process for the NFS protocol has unexpectedly quit. When I enter the share in the fstab, I can mount it with Dolphin, but this has nothing to do with Zeroconf. Greetings