Hello,
I've encountered a situation where running `tar` with incremental backup
/ restore give unexpected results when passing `tar` parameters that are
files, not directories.
Expected:
Assuming these exist:
./source/file1
./source/file2
then running:
tar --listed-incremental=file.list try1.tar ./source/
creates try1.tar with ./source/file1 and ./source/file2, and file.list
contains:
GNU tar-1.35-2
176170693758119603001761706937579935115645124855146./sourceYfile1Yfile2
So far, so good.
Then run these commands:
rm ./source/file2
touch ./source/file3
Running `tar` again, passing in a file glob (expanded to a list of
files) instead of a directory appears to work:
tar --listed-incremental=file.list -cvvf try2.tar ./source/file3
adds ./source/file3:
-rw-r--r-- root/root 0 2025-10-28 20:04 ./source/file3
However, now file.list (our --listed-incremental file) is invalid:
GNU tar-1.35-2
1761707082792347280
After extracting try1.tar then try2.tar, this results in a destination
directory containing
file1
file2
file3
When passing in a directory to all `tar` invocations, the results are as
expected:
Extracting ../try2.tar with "--listed-incremental=../file.list"
drwxr-xr-x root/root 15 2025-10-28 20:09 ./source/
tar: Deleting ‘./source/file2’
-rw-r--r-- root/root 0 2025-10-28 20:09 ./source/file3
I understand that file globs as parameters means tar cannot know that a
file was deleted from source thus should not delete it from target.
Proposed Solution
-----------------
An incremental archive that receives files instead of folders as
parameters should issue a warning and / or should fail entirely.
Perhaps the documentation should mention this too?
Note that -G (--incremental) has similar issues, minus the invalid
"file.list" snapshot file.
Thanks!
