<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/105831/">http://git.reviewboard.kde.org/r/105831/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On August 3rd, 2012, 8:48 a.m., <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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"...</pre>
</blockquote>
<p>On August 3rd, 2012, 12:47 p.m., <b>Lamarque Vieira Souza</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On August 5th, 2012, 9:32 a.m., <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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().</pre>
<br />
<p>- Lamarque Vieira</p>
<br />
<p>On August 2nd, 2012, 9:31 p.m., Lamarque Vieira Souza wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kdelibs.</div>
<div>By Lamarque Vieira Souza.</div>
<p style="color: grey;"><i>Updated Aug. 2, 2012, 9:31 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kio/kio/copyjob.cpp <span style="color: grey">(8dde763)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/105831/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>