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


I'm not sure this makes sense. You drag-n-drop a symlink called "link" to a 
file called "target" from fish://myhost to your local $HOME, and you end up 
with a broken symlink, given that "target" is nowhere to be found?

The logic of the test isn't about "does the protocol support creating symlinks" 
(kio_file certainly does), it's about whether it makes sense to copy a symlink 
as a symlink when copying it "out of the original location 
(protocol+host+port+login).

The now-lost bug 5601 was about going into an FTP folder that is full of 
symlinks (e.g. pointing to release tarballs), and (as a user) copying one of 
these to your HOME, in order to download the tarball. Ending up with just a 
symlink is kind of pointless. The exact same case could be made for FISH or 
NFS, the source protocol is rather irrelevant here.

The real problem is "what does the user really intend to do here" (if you were 
copying the full hierarchy including the target files then you would probably 
want the symlinks to stay as symlinks...)

Maybe the solution lies in offering more choices to the user, yet again... i.e. 
when dragging a symlink, offer "copy target" in the popupmenu, while 
copyNextFile() (which is also called when dragging entire directories) should 
copy symlinks "as is"...

- David Faure


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
> 
>

Reply via email to