https://bugs.kde.org/show_bug.cgi?id=517067
--- Comment #4 from antonio <[email protected]> --- (In reply to Méven from comment #3) > (In reply to antonio from comment #2) > > (In reply to TraceyC from comment #1) > > > I'm able to reproduce this with Dolphin built from git-master (26.03.70) > > > Note: The resulting incorrect group ownership for me was my logged in > > > user, > > > rather than root > > > > The problem seems to be broader, I notice that the directory permissions > > have been copied incorrectly. > > Here are more examples of directory permissions and how Dolphin copied them > > (the move is fine, however). > > > > drwx---rwx -> drwxr-xr-x > > drwxrwxr-x -> drwxr-xr-x > > d--xrwx--- -> drwxr-xr-x > > This is part is expected behavior: a copy is a file creation and as any new > file in Unix they should get the default umask. > > Dolphin can't have really runtime options as cp has ("-p" "-a"...), it has > to pick a sensible default. > Use cp or other tools if you want more fine grain control or use the file > properties dialog to correct the permissions after the copy. > > The group though should be carried over though. > > > - The problem is specific to copying directories, not individual files. Hi, the problem occurs exclusively with directories; when copying individual files, permissions are preserved correctly. Both operations should follow the same attribute transfer logic, so this difference seems like a code inconsistency. Keep in mind that Linux systems are often used for work: in these contexts, the ability to preserve attributes is an essential feature. Otherwise, the alternative is to resort to the console, negating the advantages of the graphical file manager. But if this feature is not considered a priority, I would at least suggest introducing an optional flag that allows interested users to enable attribute preservation. -- You are receiving this mail because: You are watching all bug changes.
