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





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







<p>- David</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>