Review Request: Allow symlink creation for kio protocols that support it

[Lamarque Vieira Souza]

> On Aug. 3, 2012, 8:49 a.m., David Faure wrote:
> > "Actually we need to test both source and destination to check if their protocols support symlink creation."
> > 
> > Haha, if we're copying a symlink, then obviously the source protocol supports symlinks, otherwise it wouldn't be there in the first place :-)
> 
> Lamarque Vieira Souza wrote:
>     I meant supports *creating* symlinks, not only *showing* symlinks. ftp kio protocol does not support creating symlinks according to its ftp.protocol file.
> 
> David Faure wrote:
>     So? If you're copying a symlink *from* FTP to the local harddrive, what should it matter, that kio_ftp cannot *create* symlinks? The symlink is there, it exists, so checking whether kio_ftp can create symlinks is totally irrelevant. Only the capability of the destination protocol matters, not the one of the source protocol.
> 
> Lamarque Vieira Souza wrote:
>     I am using that heuristics to avoid the symlink with ftp problem to come back (bug #5601). If I just test the destination protocol it will always create a symlink if the destination protocol is "file". We could call KIO::symlink() if both source and destination are local, do you know a way to detect that besides checking if QUrl::host() is empty?
> 
> David Faure wrote:
>     You realize how wrong that heuristic is, right? It's testing for something completely unrelated to the operation at hand, just to exclude FTP, in order to work around a problem, which isn't even specific to FTP (the issue that we sometimes want to copy symlinks as is, and sometimes to copy their target).
>     
>     You can detect "pseudo-local" protocols using KProtocolInfo::protocolClass(url.protocol()) == ":local", but this sounds like a hack too.
>     
>     Don't you agree that the real fix would be to copy source URLs (i.e. objects actually dragged by the user) by following symlinks, and to copy symlinks as symlinks otherwise (when we encounter one inside a directory that we're copying)?
>     This doesn't help with the issue that FTP can't distinguish symlinks to files and to directories, but that's orthogonal, let's use fish or sftp as examples instead, if they do distinguish these correctly.

I am aware that my heuristic is not a perfect solution. kio_fish shows the same problem kio_ftp does. I like your proposal. If we remove the "only run symlink() if both source and destination use the same protocol" from kdelibs it works almost like that. Of course, if the destination does not support symlink we must copy the target instead and that can be a problem if the target is a directory. Currently, kdelibs creates all directories first before copying the files inside the directories, but by the time this part of source code run the directory creation loop has already finished. If you are right that the problem of not distinguishing link target type is in the protocol then we would have to fix that for ftp and fish at least. I am not sure that this last problem is in the protocols. I will take a look at this problem when I have more time.


- Lamarque Vieira


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105831/#review16814
-----------------------------------------------------------


On Aug. 2, 2012, 9:31 p.m., Lamarque Vieira Souza wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105831/
> -----------------------------------------------------------
> 
> (Updated Aug. 2, 2012, 9:31 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> -------
> 
> Some kio protocols support creating symlinks but a change in kio/kio/copyjob.cpp hardcoded symlink creation to only when source and destination protocols are the same. That change was added to fix a problem with ftp protocol creating symlinks instead of copying files (there is a comment in the source code about that). I think instead of forcing source and destination use the same protocol we should test if the destination protocol supports creating symlinks (ftp protocol does not). That would allow kio's like fish and nfs create symlinks. I am also working on some other changes that could use this feature.
> 
> 
> Diffs
> -----
> 
>   kio/kio/copyjob.cpp 8dde763 
> 
> Diff: http://git.reviewboard.kde.org/r/105831/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Lamarque Vieira Souza
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120806/a1d60b61/attachment.htm>