I hope this problem is not already solved - i didn't find a bug for it. Krusader (package) version 2.3.0-beta1 in Debian stable AMD64 When i copy a folder from FTP it is created with dr-xr-xr-x and is not writable. So the rights must be altered manually every time. How can this problem be solved? Reproducible: Always Steps to Reproduce: Copy a directory via FTP Actual Results: dr-xr-xr-x Expected Results: drwxr-xr-x
I cannot reproduce this bug using krusader 2.4.0-beta3; a copied folder gets drwxr-xr-x permissions on my machine. I do not know whether there was a bug fix or if additional conditions have to be met in order for the bug to occur; would appreciate additional testers and/or comments!
Hmm - that's a pity. Maybe i must try to compile the actual version. Another chance would be if you can say me how the FTP-Client is working in Krusader. Which library or client is used? Somewhere the default file creation mask must be defined?
I'm not really a krusader guru, so far I've just commited a few simple patches so somebody more knowledgeable can probably provide more info. Disclaimer aside, krusader uses KDE's KIO for FTP operations. No work on this turns up in git logs (I went through commits back until 2009). A quick glance through the code doesn't turn up much regarding permissions, either, so perhaps this is an upstream bug that was fixed in some version of KIO?
There are many requirements and prerequisites to compile krusader ... I downloaded the sources of krusader-2.3.0-beta1 krusader-2.4.0-beta3 and found .../krusader/Dialogs/newftpgui The files are binary identical! In .../krusader/VFS/ftp_vfs i found a little difference in an additional parameter "false"! I have no idea if this can cause this? temp = new vfile(name, size, perm, mtime, symLink, false, getuid(), getgid(), mime, symDest, mode, rwx); else { QString currentUser = vfs_origin.user(); if (currentUser.contains("@")) /* remove the FTP proxy tags from the username */ currentUser.truncate(currentUser.indexOf('@')); if (currentUser.isEmpty()) { if (vfs_origin.host().isEmpty()) currentUser = KRpermHandler::uid2user(getuid()); else { currentUser = ""; // empty, but not QString() } } temp = new vfile(name, size, perm, mtime, symLink, false, kfi.user(), kfi.group(), currentUser, mime, symDest, mode, rwx, kfi.ACL().asString(), kfi.defaultACL().asString());
On OpenSUSE I only needed the package kdebase4-workspace-devel to build krusader (though I may have had helpers like gcc, make, cmake and other dev packages already installed). That false parameter you found seems to mean that the link is not broken (according to vfile.h) - vfiles are used to render the user interface and since you can style broken links differently a vfile must have this property set. That block of code seems to only support the GUI. As far as I can see the actual copying happens in ftp_vfs::vfs_addFiles; the relevant code block looks like this: case KIO::CopyJob::Copy: job = KIO::copy(*fileUrls, destUrl); break; The fileUrls is the list of files & folders that need to be copied in form of KUrl objects. KUrl doesn't handle file permissions (looking at KUrl.h) so this is why I am assuming KIO does all the copying work, including setting the permissions. This seems more and more like an upstream problem but I would still prefer a more 'official' confirmation.
I understand - it seems not to be a problem of the krusader coding. The problem seems to be in the deep of the KDE KIO interface. I searched for it, but found no useful information about details of KIO FTP. Is it possible to move this bug report to KIO of KDE? Thanks for analyzing!
I cloned the KIO repository and found nothing relevant with git log --oneline | egrep -i '{ftp|perm|folder|mode|dir|write}' I don't really know what the best action would be - either post a bug report for component KIO or maybe ask on their appropriate mailing list first..
O.K. It's not so easy to find and join the correct mailing list. So i opened this bug in KIO: https://bugs.kde.org/show_bug.cgi?id=335101 Cheers Karsten
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.