> 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?
I not aware of any sftp server that I can test 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 > >
