Review Request 128618: Fix creating symlink in Folder View

[David Faure]

> On Aug. 12, 2016, 9:37 a.m., David Faure wrote:
> > I don't feel confident about this change, for lack of unit tests.
> > 
> > Please add unittests near kio_desktop (not in kio, which can't use kio_desktop).
> > You can use my (new) tests in kio's jobtest.cpp as starting point:
> >     void createSymlink();
> >     void createSymlinkAsShouldSucceed();
> >     void createSymlinkAsShouldFail();
> > and add tests for any other code path you see in your code.
> 
> Chinmoy Ranjan Pradhan wrote:
>     I think a much simpler way would be to overload kio::link. What do you say?
> 
> David Faure wrote:
>     I don't follow, please expand your thought.
> 
> Chinmoy Ranjan Pradhan wrote:
>     There are some assumptions in CopyJob. First, the dest is expected to be the destination directory. And then it is assumed that the final file will have the same name as that of source file(unless the file already exist). Although CopyJob can create files with different names but that doesn't comply with these assumptions. 
>     That's why i feel there should be an overload for creating files. This will start the job with source's url and destination directory and will store the filename in a separate variable which can be used after stating the destination to prepare the final dest url.
>     
>     /*This is what i understood from the code. Please correct me if i am wrong*/

Your assumptions are wrong :-)

First, in CopyJob, the dest can be a directory or the final filename. This is just like the "cp" command-line tool:
cp file1 subdir          # will create the file subdir/file1
cp file1 subdir/dest     # (where dest doesn't exist) will create the file subdir/dest
See the comment about the 6 cases in CopyJobPrivate::sourceStated (the above only mentions case 4 and 6).

Being able to differenciate between these cases is the reason for DEST_IS_DIR vs DEST_IS_FILE vs DEST_DOESNT_EXIST.

The case where "dest" exists already but as a directory is the reason for copyAs/moveAs/linkAs: if we meant to create a file called "dest", we didn't mean to create a "subdir/dest/file1" like KIO::copy would do. This is why KNewFileMenu uses copyAs, and should use linkAs for creating links.

I don't think any further overloading is needed, all cases are covered, from the API point of view.

The code you mention (adding the filename to the dest dir, when not using copyAs/moveAs/linkAs, is what lines 650 and following do). But if you use linkAs, you shouldn't even have to care about that. Please switch to linkAs, and write unittests -- if needed I can do the actual patch for CopyJob once the tests exist.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128618/#review98236
-----------------------------------------------------------


On Aug. 9, 2016, 3:20 p.m., Chinmoy Ranjan Pradhan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128618/
> -----------------------------------------------------------
> 
> (Updated Aug. 9, 2016, 3:20 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> KIO::link creates symlink when either protocol+host+port+username+password of the source and the link are same or the link is going to be created locally. In case of plasma's folder view none of the above cases are true therefore creating a symlink in folder view plasmoid gives an error.  
> This patch aims to fix this issue.
> 
> 
> Diffs
> -----
> 
>   src/core/copyjob.cpp 8d6ab05 
> 
> Diff: https://git.reviewboard.kde.org/r/128618/diff/
> 
> 
> Testing
> -------
> 
> All tests pass.
> 
> 
> File Attachments
> ----------------
> 
> error message
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/08/06/d4da6ff3-53d8-49d1-a826-0c8cf12d7aa0__symlink_folderview.png
> 
> 
> Thanks,
> 
> Chinmoy Ranjan Pradhan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160813/2ec28e36/attachment.html>