Version: 1.3 (using KDE 4.3.1) OS: Linux Installed from: Ubuntu Packages When I copying or moving files from my EXT4 FS to a NTFS or FAT(32) FS and Dolphin (also happens with Konqueror) can't change files permissions it shows a Dialog to tell me it. But this Dialog does not have an option such as "Don't show this message again", so if it cannot change the permission for 100 files, it will show 100 Dialogs. It would be good if: 1) there was an option "Don't show this again" 2) all the errors were shown only once, when the copy/move has finished (as a big list of all errors) * Sorry for putting it in Dolphin section, I don't know where is the best place...
Confirming this happens in openSUSE 11.2 RC2 as well. Dolphin 4.3.1-5.6.3. Endless flood of error dialogs (as soon as you open one, the next pops up). Waiting for the entire copy operating to finish and clicking ok (the only option) end it. This really should be done with a checkbox for "Don't show me this error again" or a button Ok to all.. or via an error without a dialog.
This is a very annoying bug because the dialog is shown for every file that is copied and it blocks Dolphin. Some months ago I tried to introduce to Linux to my brother and I installed it Kubuntu Jaunty. He liked the look of KDE in general but he usually copies a lot of files from the filesystem to his backup partition and USB drives. Using it for a week was enough for him to ask me to remove the message and I couldn't do it. I had to install Nautilus and put an icon in his desktop. Now, Nautilus does not integrate with KDE at all and it tries to open files with the GNOME applications instead of the KDE ones so, explaining him why he had to use two different file managers (one to browse and one to copy) increased his "Linux sucks" impression. Using plasma notification or a "Don't show again" or "Ignore all" option would be a good solution but blocking Dolphin for such a stupid message is not the best solution, I think.
It could just show a message in the status bar, like when it cannot mount a partition...
It appears that part of the underlying problem is with detecting whether a file system supports the notion of permissions. For me (using KDE 4.3.2), the dialog does not show up when copying to a VFAT filesystem, but it does when copying to NTFS. I traced it by making each instance of the string "Could not change permissions" distinctive; it turns out that the dialog originates on lines 276-277 of file_unix.cpp in kioslave: if ( mp && mp->testFileSystemFlag( KMountPoint::SupportsChmod ) ) warning(i18n("Could not change permissions for\n%1", dest)); I then went to look at KMountPoint::testFileSystemFlag (in kio, in the file kmountpoint.cpp), and found that it has a list of filesystem types, and if the filesystem is one of them, it sets a variable called isMsDos to true. If isMsDos is true, ::SupportsChmod returns false. Unfortunately, just detecting the filesystem type doesn't help here since NTFS-3g is a FUSE driver and consequently shows a filesystem type of fuseblk, which could include filesystems other than NTFS. Perhaps a better way to go would be to do a quick series of tests on a filesystem that's just been opened, and then store those results? This would make the system immune to problems when new filesystem types are added.
Good analysis, thanks! Doing tests sounds slow and complicated, how about we hide this warning for all fuseblk filesystems? I don't think it is actually that useful, to the point where it would be a problem to miss the warning in cases where the filesystem actually supports chmod?
That seems reasonable, as long as KDE still tries to do the chmod (for the benefit of fuse filesystems that do support chmod, chown, etc.), but fails silently in the case of filesystems that don't support it. The list of "no warnings" filesystems should probably include a few different variants actually; according to https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/92099, an ntfs-3g filesystem can show up as fuse, fuseblk, fuse.ntfs-3g, or fuseblk.ntfs-3g. Future kernels will probably be moving towards showing the .ntfs-3g subtype. Actually, when I mount an sshfs, it shows up as fuse.sshfs, so there is some support for showing subtypes in /etc/mtab and /proc/mounts already.
Bug 221192 contains more useful information too.
*** Bug 221192 has been marked as a duplicate of this bug. ***
@Peter: could something be done on Dolphin level ?
*** Bug 179970 has been marked as a duplicate of this bug. ***
@Dario: no, on Dolphin level nothing can be done here
*** Bug 223068 has been marked as a duplicate of this bug. ***
*** Bug 230913 has been marked as a duplicate of this bug. ***
@David Faure This also happens while accessing samba shares, not only on NTFS. http://ubuntuforums.org/showthread.php?t=1187116 Ref: http://api.kde.org/4.x-api/kdelibs-apidocs/kioslave/html/file__unix_8cpp_source.html http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kmountpoint_8cpp_source.html
*** Bug 259124 has been marked as a duplicate of this bug. ***
*** Bug 282483 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
*** Bug 282634 has been marked as a duplicate of this bug. ***
Ping? FWIW, is it really that difficult to hide this message?
Just had to deal with an endless series of such dialogs... ... then I remembered I've been seeing this behavior for ages and wondered why it was still here. Anyway, +20 votes for this bug.
(In reply to comment #20) > Just had to deal with an endless series of such dialogs... FWIW, just leave the first instance of the dialog open, let the copy process finish, and then click it away. If you do this while the copy process is still underway, then you'll get one dialog for each file until the process is finished.
So this IS a bug. I have a synology NAS with a shared folder mounted via Gigolo on KDE. Yes Gigolo because smb4k isn't fit for purpose (another story). Anyway, if you use the CMD line to copy a file to the .gvfs/shareblah folder there's no prompt. It's only the Dolphin GUI that has this message. So why is there no error message on the console vs Dolphin ???
Any progress on this one? This is happening since three years, easy fixes and workarounds are available, and this problem happens very often and is a big usability blocker, and very visible to users. Please fix.
Git commit 51c00963ce4d27b016cf11f71a96dea7a9da02af by David Faure. Committed on 20/08/2012 at 20:51. Pushed by dfaure into branch 'KDE/4.9'. NTFS doesn't support chmod, so ignore chmod errors when copying files. FUSE doesn't make it easy to detect NTFS mounts, though... In this code we have to hardcode "fuseblk" and hope that more recent versions of FUSE indeed show "fuseblk.ntfs-3g" instead, as a bug report suggested. But even worse: I want to replace this code with KFileSystemType which uses statvfs(), which is much faster and less code, but on linux that method returns the same number (FUSE_SUPER_MAGIC, 0x65735546) for all fuse filesystems :( Also add SMB/CIFS mounts to the list of filsystems "made by microsoft and therefore doesn't support chown, chmod, utime, nor proper symlinks". FIXED-IN: 4.9.1 M +6 -1 kdecore/io/kmountpoint.cpp http://commits.kde.org/kdelibs/51c00963ce4d27b016cf11f71a96dea7a9da02af
Hi. Recently I got this error with KDE 4.12.5
Confirmed to KDE 4.13.3
confirmed with 4.14.2
Problem still exists in plasma 5.3.2 with ntsf as well as fat32 ( tested with ssh network mounts in dolphin 15.04 )
Confirmed for KDE 4.14.9
*** Bug 351545 has been marked as a duplicate of this bug. ***
Problem still exists in Plasma 5.5.5-1 (Dolphin 15.12.2) on CIFS mount (Samba 4.3.5-1) on Arch.
The same problem still persits also when copying files to a remote SFTP folder with Plasma 5.9 / Dolphin 17.03.70.
This issue still exists on Plasma 5.11.5 / KIO 5.42.0 (Arch Linux) when copying files from my local btrfs partition to my CIFS mounted FritzBox NAS storage (using krusader). This bug only occurs with this specific CIFS mount. I could not reproduce it with other SAMBA servers. https://imgur.com/a/aCJYH The relevant fstab line: //192.168.1.1/##### /mnt/fritzbox cifs nofail,users,username=###,password=###,vers=1.0,x-systemd.automount 0 0 Please reopen this bug. Is this warning even necessary/useful? It is very probable that the user is spammed with this message for every single file that he copies. I cannot think of a scenario where a directory is copied and chmod/chown fails (and there is a legitimate issue) only for a select few files. In the current state, it is easier to open a terminal and kill the file manager than to click through the thousands of warnings until you can reach the close button of the file manager. A much better solution would be to show all errors once in a dialog when all files have been copied, or to open a dialog for the first error and then append all other errors to it.
Yes, regression during recent refactoring. https://phabricator.kde.org/D10358 is about to fix it.
*** Bug 196042 has been marked as a duplicate of this bug. ***