--as-path <PATH> option skips empty string

[F3-L1x]

Hello wonderful people,

at first, I'm so grateful for this great project. :3

Just a minor thing.
I noticed, that using the '--as-path' cli-option (when creating a backup) doesn't recognize an empty path, while the configuration-option does.
It would be nice, if both had this ability.

Thank you for your time. (:

[aawsome]

Thanks @F3-L1x for opening this issue!

Can you please write how you did run the CLI command?
Did you try to use --as-path ""?

[F3-L1x]

Wow, what a fast reply.^^
You're welcome. (:

I tried it different ways:

1. With minimal configuration (only specifying host, no-cache, password-file and repository-name) rustic backup --as-path "" ./ I get:

error: no backup source given.

2. Same minimal config as in 1. and command rustic backup --as-path="" ./ gives:

error: a value is required for '--as-path ' but none was supplied

3. With a little more extensive configuration (additionally containing: backup.sources/source = "." and some other stuff) rustic -P local backup --as-path "" ./ returns no errors, but rustic -P local snapshot shows an absolute path, rather than a relative.
4. When additionally adding backup/as-path to the config-file, rustic -P local backup ./ gives me the result, I wished for.
   (No errors and showing an (empty) relative path when using snapshot-cmd)

[aawsome]

First, am I right that your original intend is to run rustic backup ./ and have it saved as a relative path? I think this should not be addressed using --as-path, but instead the path sanitizing should be enhanced fixed such that it handles a leading .. I'll look after that.

Moreover, I think that in fact there shouldn't be a use-case where you need to use an empty --as-path, but use --as-path=. (with a fixed path sanitizing, see above) or -as-path=/ (which already works).

Still, digging a bit into details:
About 1. and 2.: I think that this is an issue of clap parsing the CLI arguments. It seems that clap treats an path "" like a not-given path. This explains why this behaves differently than specifying as-path in the config profile. However, I cannot reproduce the behavior described in 1.

About 3: This is treated by clap like no --as-path would be given which explains this current behavior.

[aawsome]

Correct handling of paths starting with . (including the paths . or ./) should be fixed by rustic-rs/rustic_core#213

[F3-L1x]

[...] your original intend is to run rustic backup ./ and have it saved as a relative path?

Yes that's what I was trying to do.

I think this should not be addressed using --as-path, but instead the path sanitizing should be enhanced fixed such that it handles a leading .. I'll look after that.

You mean, it should be automatically saved as a relative-path, when using ./ as backup source-path?
I thought of it beeing two separate things. 1. Selecting the working dir with ./ and after it choosing to back it up either as the absolute path or relative by using the --as-path - option.
I actually like, that the user can decide, whether it will be saved relative or absolute (even, when using a relative path as a source).
But maybe, I didn't understand you correctly here.

Thanks for you tip with the:

-as-path=/

That did the trick. (:
And as you've mentioned, -as-path='.' / -as-path='./' didn't work properly,
I ended up using an empty string, rather than -as-path=/, as this looked like an absolute path to me (even if when was on Windows).

Thank you for your super quick help and I'll try your fix soon. :) 👍

Edit:

However, I cannot reproduce the behavior described in 1.

It looks like, this has sth. to do with, how powershell handles parameters/arguments (probably discarding empty strings and gobbling the next available argument/option). I get a different output from cmd and msys-bash:

error: a value is required for '--as-path ' but none was supplied

For more information, try '--help'.

[aawsome]

You mean, it should be automatically saved as a relative-path, when using ./ as backup source-path?

Exactly. This is also the current behavior if you backup a relative path without leading .. So it should be consistently the identical thing with a leading . - and that's what's implemented in the mentioned PR.

If you want to backup an absolute path, you can simply specify the full path.