option to accept full slice names
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
Please add an option for dar not to add ".<number>.dar" to slice names when creating files and not to complain about using full slice names when reading/modifying archives.
Currently dar complains when full slice name is used: "seems more to be a slice name than a base name. Do you want to replace it by..."</number>
Detection of partial path and optional adding ".<number>.dar" when reading archives would be nice to keep.
This also would only make sense when "-s" option is not used, in which case I believe this option could be ignored.</number>
This would dar look more like tar where full filenames are used, but would make dar backward-compatible.
1/ adding "<number>.dar" to basename is done by design. You should provide the same basename to read an archive as the one you provided at archive creation, dar does not ask you to add those extra '<number>.dar' characters. So the warning issued by dar is sane as normally dar should just fail, it gives you a chance to fix that mistake without having you to restart from the beginning with the correct argument.</number></number>
2/ even using -s option you can end with a single sliced archive (slice size is larger than the (eventually compressed) data to backup). There is no difference between a single sliced archive created with or without -s option, the <number>.dar is thus always present. This is still by design.</number>
Seen 1/ and 2/ above, the problem you underline is that by laziness (I am acting that way too, no offense) you rely in shell completion which adds those extra characters.
To cope with that, dar now removes the extra <number>.dar characters when this would else lead to an execution error. The warning you mention is still present but will not ask you for confirmation so you should transparently use shell completion with dar without worries anymore.</number>
Feature now implemented in version 2.7.0 just release.
Closing this feature request.
Cheers,
Denis