#31 xc: handle no write/access perms / bad paths on remote side during copies

Open
opened 8 months ago by Russtopia · 1 comments

TODO: characterize all failure modes relating to permissions (mostly server-side which must be communicated to local clients).

Eg.,

server -> client: If remote (server) side gets (read) perm denied, propagate to client exit code

client -> server: If remote (server) side gets (write/mkdir/readdir) perm denied, propagate to client exit code

Useful to give smth more verbose than "Permission denied", rather "Local: permission denied (dir/file)" vs. "Remote: permission denied (dir/file)" / "Remote: no such dir/file" etc.

TODO: characterize all failure modes relating to permissions (mostly server-side which must be communicated to local clients). Eg., server -> client: If remote (server) side gets (read) perm denied, propagate to client exit code client -> server: If remote (server) side gets (write/mkdir/readdir) perm denied, propagate to client exit code Useful to give smth more verbose than "Permission denied", rather "Local: permission denied (dir/file)" vs. "Remote: permission denied (dir/file)" / "Remote: no such dir/file" etc.
Russtopia commented 7 months ago
Owner

Mitigated by commit b016e3cd7

Downgraded from [1]bug to [3]glitch

Added README.md notes on how to check before a copy for proper permissions, and/or existence on server-side to avoid clobbering pre-existing dest paths.

Ideally the protocol someday could be improved to allow the server-side of the tarpipe to complete without the client closing the connection completely (and thus precluding server sending its completion status to client); however it'll take study to determine how to achieve this.

Presumably one knows about the server-side before copying stuff and isn't just blindly blasting things across the wire to it so it seems reasonable to use xc first to check if that's really a concern.

Mitigated by commit b016e3cd7 Downgraded from [1]bug to [3]glitch Added README.md notes on how to check before a copy for proper permissions, and/or existence on server-side to avoid clobbering pre-existing dest paths. Ideally the protocol someday could be improved to allow the server-side of the tarpipe to complete without the client closing the connection completely (and thus precluding server sending its completion status to client); however it'll take study to determine how to achieve this. Presumably one knows about the server-side before copying stuff and isn't just blindly blasting things across the wire to it so it seems reasonable to use `xc` first to check if that's really a concern.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.