> On Aug. 3, 2012, 8:48 a.m., David Faure wrote:
> > 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"...
> 
> Lamarque Vieira Souza wrote:
>     One of the uses for this is archiving a directory with symlinks, 
> specially symlink to a directory. The user may not be interested in archiving 
> the directory itself and currently kio creates an empty file everytime it 
> copies a symlink to a directory (it treats symlinks to directory like 
> symlinks to a file), so nothing is actually copied.
> 
> David Faure wrote:
>     Empty file? That sounds like a bug in the symlink() implementation of the 
> destination kioslave, no?
>     This code is supposed to create a symlink at the destination. If anything 
> else happens, then that should be fixed, rather than skipping the creation of 
> the symlink.
> 
> Lamarque Vieira Souza wrote:
>     It's not a bug in symlink() because it is never called by kdelibs when 
> source and destination protocols are different. In that case if you try to 
> copy a symlink to a directory kdelibs tries to copy the target as a file, 
> which obviously does not work when the target is a directory. For example, 
> try to copy ftp://ftp.kde.org/pub/kde/snapshots (a symlink to directory) to 
> your home directory using Dolphin. It will failed with a message 
> "ftp://ftp.kde.org/pub/kde/snapshots is a folder, but a file was expected.". 
> That happens because kdelibs is calling KIO::file_copy() instead of 
> KIO::symlink() or CopyJobPrivate::createNextDir().
> 
> David Faure wrote:
>     I see. This is not a bug in kdelibs, but in kio_ftp, because it cannot 
> distinguish a symlink-to-a-file from a symlink-to-a-directory (this would 
> require issuing multiple FTP commands, changing directory to the target and 
> listing it).
>     
>     I'm pretty sure that if you try this with kio_sftp there is no such issue?
> 
> Lamarque Vieira Souza wrote:
>     I not aware of any sftp server that I can test kio_sftp.

Ok, kio_fish and kio_sftp also fail to copy the symlink to directory with a 
different message "Could not read file <url>". It seems they are also treating 
symlink to directory as symlink to file. If I click on the symlink Dolphin 
enters the directory correctly using either kio_fish or kio_sftp.


- Lamarque Vieira


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


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