Version: (using Devel) Installed from: Compiled sources OS: Linux Having mounted a remote samba share via cifs (or smbfs) i noticed dolphin crashes / freezes when trying to change the sort mode or view mode on a directory that my user has no write-permissions on the server. (yet the share is being mounted as rw). Changing the mount options to ro (read-only) fixes the issue, yet I think dolphin shouldn't crash / freeze in such a situation, but handle the error gracefully. It appears it tries to write a lock-file in this directory - which it obviously fails to do.
I experience the same kind of freeze of dolphin on my NAS (mounted "rw") when trying to switch the view mode from "icons" to "details". However, I have write permissions on the directory. BTW: Thanks a lot for dolphin - it is a great application!
I have the problem, too, with trunk (kdebase rev. 816127). If I remove the .directory.lock file by hand (which I can do as the same user as dolphin runs on cifs), dolphin unfreezes and changes the settings. I guess it should a) not freeze on any view mode changes and at least timeout and b) should work in default here. But this is only my 2 pence. I hope you fix it somehow. Cheers, duns
I can confirm Dolphin hangs on change of view mode while navigating cifs mount. When run from command line, it complains of "problem deleting stale lockfile". Deleting .directory.lock manually does unfreeze but only until the next view change. Since I mount most of my home directory over cifs, this is a bit of showstopper. Using Dolphin Version 1.0.99 KDE 4.00.83 (KDE 4.0.83 (KDE 4.1 Beta2)
The issue is on my TODO-list and I've increased the priority, but I cannot promise that it will be fixed until KDE 4.1 final.
Confirmed. Makes file management impossible for those folders, is there a temp workaround or can you explain more about the cause?
@Tom: A temporary workaround is to enable "(x) Use common view properties for all folders", by this Dolphin won't write the .directory files. The fix should not be difficult I hope, but the next 2 weeks I've quite less time for Dolphin :-(
@David: I cannot reproduce this issue - although I've write access to my samba-share, Dolphin (correctly) stores the .directory files mirrored inside ~/.kde4/share/apps/dolphin -> no locking. I had a look at the code and from my point of view Dolphin should never try to write on non-local directory. Inside ViewProperties.cpp there is the following check (simplified here - 'url' is the input, m_filePath the path where the .directory file will be written): KUrl cleanUrl(url); cleanUrl.cleanPath(); m_filepath = cleanUrl.path(); ... if (cleanUrl.isLocalFile()) { const QFileInfo info(m_filepath); if (!info.isWritable()) { m_filepath = destinationDir("local") + m_filepath; } } else { m_filepath = destinationDir("remote") + m_filepath; } Where destinationDir() is implemented like this: QString ViewProperties::destinationDir(const QString& subDir) const { QString basePath = KGlobal::mainComponent().componentName(); basePath.append("/view_properties/").append(subDir); return KStandardDirs::locateLocal("data", basePath); } I'm confused now as cleanUrl.isLocalFile() should return false in the case of cifs/smbfs and hence never may touch the .directory file. And even if true would be returned, then isWritable() may not return true if it is not writable. From a quick look at this code: Do you see a general flaw here? Thanks!
(for me this is about cifs mounted shares, so that would be /home/toma/someserver/networkshare/)
@Tom: Ah, this would explain why at least cleanUrl.isLocalFile() returns true. Hmm, I'm still wondering when fileInfo.isWriteable() returns true why it still locks...
yes, it looks like dolphin checks the timestamp on the .directory file like: "m_node->timestamp() < settings->viewPropsTimestamp()". I'm pretty sure this is error prone for mounted devices, as it will probablt get the server timestamp. So if the date/time on the server does not match exactly the one on the client, this could cause trouble in theory. I just can't see how it could make dolphin hang though. Maybe this helps.
*** Bug 162816 has been marked as a duplicate of this bug. ***
*** Bug 168407 has been marked as a duplicate of this bug. ***
*** Bug 151112 has been marked as a duplicate of this bug. ***
Confirming I have this bug also - openSUSE x86_64 rpms, using a CIFS-mounted filesystem. Trying to change the view to detailed view, to image preview or any other change to the basic folder view causes Dolphin to crash.
Additional behaviour I've observed: Dolphin will crash if you try to switch view or sort mode on ANY directory, whilst you have a SMBFS/CIFS directory open. So, if you have an SMBFS/CIFS window open, split the view, use the second pane to navigate through the local filesystem and then try and change view/sort mode on the local fs, Dolphin will freeze as there is an SMBFS/CIFS window open, even though this is not the directory you are trying to sort. This applies even if the SMBFS/CIFS system is open in a completely Dolphin window; changing view or sort on the local fs will still cause Dolphin to freeze.
It seems to me that this bug also affects Konqueror, not only Dolphin. Since networking is a somewhat essential feature of a Linux box I'd be very happy to see this bug fixed soon! (Along with the printing issues :) I am using the KDE4:factory repo from the openSUSE Buildservice for the future 11.1 release.
Is there any news on this issue? It makes everyday real-life usage experience with KDE4 a hellish nightmare...
same here with KDE 4.1.1, thanks for the workaround, Christian Weilbach! I'd even build dolphin from SVN for this issue to get resolved, please get back to this bug as soon as you can, Peter Penz.
Doh, I first tested with a NFS mount, but those work fine. With smbmount I see "couldn't lock local file" indeed, for a readonly mount (this is because smbmount doesn't adjust permissions like nfsmount does, for a readonly mount, so the permissions seem to indicate that the directory is writable, while it is not). Ah, with a readwrite mount I finally get the bug. WARNING: Problem deleting stale lockfile /<path>/.directory.lock WARNING: Problem deleting stale lockfile /<path>/.directory.lock etc. forever. Definitely a KLockFile bug. Investigation showed: lockFile() always returns LockFail, even though it creates the lock file fine. 173 if (st_buf != st_buf2 || S_ISLNK(st_buf.st_mode) || S_ISLNK(st_buf2.st_mode)) 174 { 175 // SMBFS supports hardlinks by copying the file, as a result the above test will always fail 176 if ((st_buf.st_nlink == 1) && (st_buf2.st_nlink == 1) && (st_buf.st_ino != st_buf2.st_ino)) 177 { [...] 181 } 182 return KLockFile::LockFail; The first if() is indeed always false, but the second one too: st_buf.st_nlink is 2, st_buf2.st_nlink is 2 as well, and the st_ino differ indeed. So I have a patch which fixes this, but KLockFile is still VERY slow locking that file (i.e. every time I click on the view mode change button!), because of the slow testLinkCountSupport() code that the snipped code in the above if runs... Ouch I wanted to ask the author of the code about all this, but that's Waldo...
Created attachment 27434 [details] patch
Dirk says he has a patch that replaces all this code with an atomic move instead. Sounds good to me :)
*** Bug 151680 has been marked as a duplicate of this bug. ***
*** Bug 165245 has been marked as a duplicate of this bug. ***
For all users which can not wait for an KDE update. Here is a workaround: Add the option "serverino" when mounting a CIFS share. I tested this which Samba 3.x on the server side. I do not know if this works with Windows on the server side too.
bjoern, thanks very much for the tip - works here too! Still looking forward to the atomic fix, though,-)
bjoern: Thanks for the tip. It solved the problem for me on two out of three shares. Just a warning though: According to the mount.cifs man page you should NOT use this workaround if your share spans more than one disk partition on the server, as that would give you duplicate inode numbers on the client (two files, same mount, same inode number = trouble).
Any news on thuis issue? This bug is still not fixed in 4.1.3 which is an annoyance since it seriously affects networking experience. I would very much appreciate any improvements here!
@David: The issue has already 100 votes, should we apply your patch in the meantime? It's unclear for me currently until when Dirk can apply his patch.
May I ask which Dirk that would be? Dirk Müller from the openSUSE team? If so, please bug him a little more to apply his patch! Thank you very much!
Porting the patch to 4.2 and 4.1 branch.
The Bug is not fixed in 4.2RC1. Hopefully it's fixed until the final version. Thx in advance.
just adding console output: dolphin(5786)/kio (KDirListerCache) KDirListerCache::forgetDirs: DolphinDirLister(0x8644c38) item moved into cache: KUrl("file:///home/jofko") dolphin(5786)/kio (KDirListerCache) KDirListerCache::listDir: Listing directory: KUrl("file:///home/jofko/kaktus") dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added Dir "/home/jofko/kaktus" for "" ["KDirWatch-2"] dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::useINotify: trying to use inotify for monitoring dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::useINotify: inotify successfully used for monitoring dolphin(5786) MetaDataWidget::setFile: KUrl("file:///home/jofko/kaktus") dolphin(5786)/kio (KDirListerCache) KDirListerCache::slotResult: finished listing KUrl("file:///home/jofko/kaktus") dolphin(5786)/kio (KIOJob) KDirModel::indexForUrl: KUrl("file:///home/jofko") not found dolphin(5786)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: WARNING: Problem deleting stale lockfile /home/jofko/kaktus/.directory.lock WARNING: Problem deleting stale lockfile /home/jofko/kaktus/.directory.lock
SVN commit 915410 by mueller: add a workaround for cifs/samba 2.x oddity. better fix in trunk. BUG: 156759 M +3 -1 klockfile_unix.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=915410
Only partially fixed here in 4.2 from http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.1/ As it seems, it works OK in smaller shares but still crashes Dolphin in larger folders: mader@santenay:/home/02_optstaff> dolphin -v Qt: 4.4.3 KDE: 4.2.00 (KDE 4.2.0) "release 83.1" Dolphin: 1.2 mader@santenay:/home/02_optstaff> dolphin "/usr/bin/dolphin(14480)" Error in thread 140428661770064 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files" "/usr/bin/dolphin(14480)" Error in thread 140428661770064 : "QLocalSocket::connectToServer: Invalid name" dolphin(14480): Attempt to use QAction "close_tab" with KXMLGUIFactory! dolphin(14480): Attempt to use QAction "show_info_panel" with KXMLGUIFactory! dolphin(14480): Attempt to use QAction "show_folders_panel" with KXMLGUIFactory! dolphin(14480): Attempt to use QAction "show_terminal_panel" with KXMLGUIFactory! dolphin(14480): Attempt to use QAction "show_places_panel" with KXMLGUIFactory! mader@santenay:/home/02_optstaff> WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock [...]
I can not confirm this - I've created 10k files for testing purposes and everything works fine. My files are at 0byte size (maybe that's the reason why it works?). But it seems not to depend on the amount of files ... for i in `seq 1 10000` ; do touch $i ; done Qt: 4.4.3 KDE: 4.2.00 (KDE 4.2.0) "release 88.2" Dolphin: 1.2
Dirk confirmed yesterday that the patch is incomplete. It does not depend on the amount of files or the size of the share, though. The problem persists with an existing .directory.lock file in the respective share. Deleting it was a workaround for me, but Dirk wants to fix the stale lock issue completely and reassigned it to him. https://bugzilla.novell.com/show_bug.cgi?id=414339
I can also confirm this bug. However, in my case appears to show up when accessing root UNIX shares and there is no accessible .directory.lock file. This bug not only freezes dolphin but also all applications which are trying to access the share (including konsole windows). Worse, many of these processes (including dolphin) share instances, and *cannot be terminated even by SysRq commands*. As a result, rebooting is necessary. This is a severe bug, and needs to be treated as such.
I even have this problem with Dolphin 16.04.1