When I access a samba share that I have R/W access to, I find that I can't create a folder via Create New > Folder as expected. Specifically, the option is greyed out. This does work when using Konqueror. I note that this behaviour has also been discussed here recently https://forum.kde.org/viewtopic.php?f=18&t=118918 Reproducible: Always Steps to Reproduce: 1.Navigate to a samba share 'smb://.... 2. File > Create New (is greyed out) 3. Actual Results: The option is not available Expected Results: Should be able to select 'Create New > Folder' as with previous KDE versions.
Thanks for the bug report. This looks like bug 330001. I haven't been able to reproduce the problem so far (with file:, sftp:, and fish:). I'm not aware of any recent changes in Dolphin that could cause such a problem (in particular considering that this happens only with some protocols). Do you build Dolphin from source? We could send you a patch that adds some debug output to DolphinView::updateWritableState(), and possibly other places, that might help to debug this problem.
I didn't build from source. I'm using openSUSE 13.1 and installed KDE 4.12.0 via the openSUSE KDE repositories. BTW, like the user (jesusrop) reported in the KDE forum thread (I linked to previously), using the F10 key to create a new folder works without issue. It's just the context menu that seems to be broken.
Thanks for the quick reply. (In reply to comment #2) > BTW, like the user (jesusrop) reported in the KDE forum thread (I linked to > previously), using the F10 key to create a new folder works without issue. This is to be expected in Dolphin 4.12.0. The "F10"-action is always enabled in this version, and all earlier versions. This has been changed in Dolphin 4.12.1 because the error message that was shown when pressing F10 in a read-only directory could be annoying (bug 294054).
*** Bug 330383 has been marked as a duplicate of this bug. ***
*** Bug 330433 has been marked as a duplicate of this bug. ***
Since we are getting reports about this issue repeatedly since 4.12.0, it seems that there is a recent change in kio_smb that caused this bug. According to http://lists.kde.org/?l=kfm-devel&m=139015381308473&w=2 the problem is probably that kio_smb does not emit a KFileItem for the path ".". Recent changes in kio_smb that are in 4.12.0 are https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/2cafde422dce082d05801abfa209010fe7ea4c68 and https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/6c0de3209da77eb10976af72307188eb68aa0689
(In reply to comment #7) I note that konqueror is not affected. Does this not use the same kio_smb?
(In reply to comment #8) > I note that konqueror is not affected. Konqueror and Dolphin use different approaches to determine if the "Create New..." action should be enabled if the empty space in the view is clicked: (a) Konqueror (or to be precise, the DolphinPart which wraps the DolphinView class and which is shown inside Konqueror) creates a KFileItem for the view's URL, and then uses the class KFileItemListProperties from kdelibs to find out if the URL that the KFileItem points to is writable. This happens every time the context menu is opened. (b) Dolphin sets the state of the menu to "disabled" when a new URL is loaded, waits until loading is finished, and then passes the KFileItem which is returned by the rootItem() method of KDirLister (the interface to the kioslaves, like kio_file, kio_smb, etc.) to the KFileItemListProperties class to find out if the URL is writable. Based on the result, the "Create New" menu, which is used in the context menu, but can also be added to the tool bar, is enabled or not. I haven't written any of the relevant code, but it is my understanding that approach (a) might block the GUI before the context menu is opened if accessing the URL takes very long. Approach (b) waits until the kioslave (which is an external process that cannot block the GUI of the application itself) has investigated the URL and found the necessary information. Approach (b) has worked fine in Dolphin before 4.12.0, but according to the bug reports, it seems that kio_smb doesn't provide the "rootItem" any more. One possibility to work around the problem would be to use (a) as a fall-back if we don't get a rootItem, see the patch from bug 330001 comment 12 (this bug is about a non-smb usecase where the same thing happens - mysteriously, it also started with KDE SC 4.12.x). If the problem in kio_smb isn't found, then we could use this workaround. But the problem with workarounds that are applied without having a clue about the root cause of the bug is that they hide the real bug, and that this bug might cause more trouble in the future.
Git commit 4865303004e1eba6e73342960bac614171323588 by Frank Reininghaus. Committed on 30/01/2014 at 21:10. Pushed by freininghaus into branch 'KDE/4.12'. Always enable the "Create New..." menu if the URL is writable This commit works around the problem that KDirLister may not provide a "rootItem" for some kioslaves by setting up a KFileItem with the view URL and using this to find out if the URL is writable. Related: bug 330001 REVIEW: 115405 FIXED-IN: 4.12.2 M +9 -4 dolphin/src/views/dolphinview.cpp http://commits.kde.org/kde-baseapps/4865303004e1eba6e73342960bac614171323588
I dunno why any of the changes listed in comment#7, which I made, have any relation to this problem. Especially it should be very evident that https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/2cafde422dce082d05801abfa209010fe7ea4c68 only prevents the ioslave from emitting finished() after it already emitted error(...) which is wrong as stated in the KIO::SlaveBase documentation. And the second commit simply deals with copy and put operations when one end (source or destination) is a local file. It does not touch anything that has to do with listing. As such I fail to see how the kio_smb changes can be the source for this bug.
However the following commit might be of interest: http://commits.kde.org/kde-runtime/b21dc0aae946b1fe66b189ecb4cf4447624156f2 It should be clear from this commit that kio_smb seems to have always, or at least for a long time, has not been sending a KFileItem for either "." nor "..". Perhaps fixing that would resolve this particular issue. However based on the report that this problem only showed up in KDE 4.12 and the fact that kio_smb has never sent an item for neither "." or "..", I am not sure changing that logic would fix this particular bug report.
(In reply to comment #11) > As such I fail to see how the kio_smb changes can be the > source for this bug. Sorry if I got that wrong. I didn't really look at the commits in details because I don't have the slightest idea about how smb works. All I know is that this bug was never reported before KDE SC 4.12.0, but multiple times after that, so I simply checked what changed between KDE/4.11 and KDE/4.12. Maybe it's just a strange coincidence then that the bug was only noticed in 4.12.
Between the aforementioned commits and various other ones, this has been fixed. I can create folders from Dolphin SMB shares in every KF5 version of Dolphin and KIO that I've tested.