Allow get/put folders from/to devices.

[tomriddly]

The original implementation of get and put of afcclient supports only single file. This PR make it work for directories.

[tomriddly]

@nikias would you please check if there is further more working or ready for merge?

[nikias]

Looks good from what I can tell from my phone, but could you
a) use tabs instead of spaces to keep the original formatting intact
b) prefix the 2 commit messages with afclient: followed by the original message (omitting 'afcclient')
(the 3rd commit for .gitignore is fine)

[tomriddly]

Looks good from what I can tell from my phone, but could you a) use tabs instead of spaces to keep the original formatting intact b) prefix the 2 commit messages with afclient: followed by the original message (omitting 'afcclient') (the 3rd commit for .gitignore is fine)

Done. Commit style and code style are changed

[mexmer]

i would suggest adding -r for recursive push/pull, and disable recursive by default. it's common practice for many other commandline copying tools also.

[tomriddly]

i would suggest adding -r for recursive push/pull, and disable recursive by default. it's common practice for many other commandline copying tools also.

(s)cp and zip do need a -r option indeed. But on the other hand, adb pull/push will do the transper no matter from a folder or file, which I thought could be the same behaviour of afcclient. I just feel it would be easy to use as what adb has done. Would it be any unforseen risk if we do recursive as default?

[nikias]

I don't mind without a -r option, but let's make sure that maybe we don't overwrite existing directories. The same actually goes for files, you could easily break your device...

[tomriddly]

I don't mind without a -r option, but let's make sure that maybe we don't overwrite existing directories. The same actually goes for files, you could easily break your device...

This make sense, we may need an extra option for overwriting exist files. This PR will write to file directly if we have the write permission(for both side, device and local file system). I would make a change later, maybe a -f flag?

[nikias]

Yes -f makes sense. Without it and existing we should abort with an error message.

[mexmer]

i would suggest adding -r for recursive push/pull, and disable recursive by default. it's common practice for many other commandline copying tools also.

(s)cp and zip do need a -r option indeed. But on the other hand, adb pull/push will do the transper no matter from a folder or file, which I thought could be the same behaviour of afcclient. I just feel it would be easy to use as what adb has done. Would it be any unforseen risk if we do recursive as default?

it's not just cp and zip, abd is rather exception, than "good example". in linux most tools that manipulate files in commandline require -r (some -R) to do recursive work.

adb is bad example for two reasons, major one is, that it does follow symlinks, and doesn't prevent cycling trough links (unless they fixed that, but that bug has been there for years), second is, that it has flawed long path handling (again, unless they fixed it over years)

as for overwrite, i agree that -f (or --force) is good choice.

[tomriddly]

i would suggest adding -r for recursive push/pull, and disable recursive by default. it's common practice for many other commandline copying tools also.

(s)cp and zip do need a -r option indeed. But on the other hand, adb pull/push will do the transper no matter from a folder or file, which I thought could be the same behaviour of afcclient. I just feel it would be easy to use as what adb has done. Would it be any unforseen risk if we do recursive as default?

it's not just cp and zip, abd is rather exception, than "good example". in linux most tools that manipulate files in commandline require -r (some -R) to do recursive work.

adb is bad example for two reasons, major one is, that it does follow symlinks, and doesn't prevent cycling trough links (unless they fixed that, but that bug has been there for years), second is, that it has flawed long path handling (again, unless they fixed it over years)

as for overwrite, i agree that -f (or --force) is good choice.

symlinks cycling is what I've never considered, which makes -r may be a necessary option.
I made some updates to support -r and -f, and fix the docs and help messages.

[mexmer]

thanks you, looks good to me.

[tomriddly]

@nikias I've run local test and did not find any issue. Could this be merged?

[nikias]

I pushed the commits with some small changes, merging the coding style fixes directly into the initial commits and prevent later code-style hiccups. Could you please check with latest commit if this works properly now?

[tomriddly]

line 916, additional argc check for get is missing:

else {
	printf("Error: Invalid number of arguments\n");
	return;
}

The other changes seem appropriate to me。

[nikias]

See 9ccc522.