Relative folder won't send

[nbommersbach]

Describe the bug

<-- A clear and concise description of what the bug is. --> I have the issue that folders that are given to croc by relative paths that include parent folders (e.g.: croc send ../data/testfolder/) won't send and croc leaves me with an error message "remote directory must be relative to current". Sending any specific document within this folder is possible (croc send ../data/testfolder/test.json) and also sending the whole folder, when the working directory the command is run in does not include to switch to a parent folder (cd .. && croc send data/testfolder/).

To Reproduce

Steps to reproduce the behavior: <-- 1. Go to '...' 2. Click on '....' 3. Scroll down to '....' 4. See error -->

1. Create two folders (test1, test2) and in folder test2 another folder test3
2. cd to test 1
3. send folder test3 by croc send ../test2/test3/
4. See error: remote directory must be relative to current

Expected behaviour

<-- A clear and concise description of what you expected to happen. --> Sending folder test3

Version

<-- Check "croc -v" and report it --> croc version v9.4.2-49f50a5

Additional context

<-- Add any other context about the problem here. -->

[bchadwic]

$ mkdir test1 test2 test2/test3
$ touch test2/test3/test
$ cd test1
$ croc send ../test2/test3/
2021/11/02 00:23:08 remote directory must be relative to current

I noticed if test3 is empty, it doesn't matter if you use relative path. Then I tried adding a file into test3 and I got the error mentioned by op. I'd like to investigate this one.

croc version v9.2.1-4b1eb65

[hamiecod]

mkdir /tmp/{test1,test2} /tmp/test2/test3
touch /tmp/test2/test3/test3.json
cd /tmp/test1
croc send /tmp/test2/test3/
2021/12/06 17:27:28 remote directory must be relative to current

I executed the above commands and noticed that the error is still thrown even if you provide an absolute path as an argument.

croc version v9.5.0-f210ef8

[hamiecod]

For the time being, you can use * to send all the contents of a folder without encountering the above mentioned error.

croc send ../test2/test3/*

This above syntax does not throw any error. I will try to fix the bug though.

croc version v9.5.0-f210ef8

[hamiecod]

Hey, I tried to look into the code issue that was causing this problem. A bug doesn't cause this issue, it is rather a feature that causes this error. The TransferOptions struct has a field named KeepPathInRemote and I couldn't find out the utility of this field due to lack of comments. The above stated error only occurs if the relative path refers to a folder(reference), that is why using * does not trigger an error as stated in my last comment.

@schollz(since they wrote the above mentioned code) or any other contributor is requested to explain why is TransferOptions.KeepPathInRemote set to true when a directory is defined in the relative path. I tried to delete cli/cli.go:370 to stop setting TransferOptions.KeepPathInRemote to true when a relative directory path is passed to croc send. This change does not break the build or cause any issues in sending files over wireless connections. I could not test the build over a LAN and using a relay but I assume that the build won't break because the changes had nothing to do with any of the communications code.

In my opinion, there could be a better fix that the above mentioned fix. The conditional at croc/croc.go:284 actually throws the error. The conditional requires the directory being sent to be located in the current working directory. I could not grasp why that is a condition for the folder transfer, it would be great if somebody could explain. Removing the mentioned if-statement also resolves the issue. I think that this is a better fix because the fix mentioned earlier does not allow croc/croc.go:274 to run which is unfavorable.

I think that a better fix can be made if the utility of TransferOptions.KeepPathInRemote is known. Submitting a pull request regarding the fix for code review.

[github-actions[bot]]

Stale issue message