Alvin Starr via Talk wrote on 2025-10-27 07:23:
When tar is actually invoked at the system call level the result is not "tar","file*" It is more like "tar","file1","file2","file3","filebob"... If you delete a file. Lets say file3 your next invocation of tar will be "tar","file1","file2","filebob"...
Right, glob expansion happens in shell before invoking program.
If you backup a directory your invocation to tar looks like "tar","/ etc/dirtobackup" You next invocation of tar will look exactly the saem even though you may have removed /etc/dirtobackup/file3 At that point if tar keeps track of the directory information in /etc/ dirtobackup it can use that to determine what files have been deleted. This part took me far too long to "get it".
You led me right to the answer, and I still didn't see the implications. Restating your point: When passing files instead of directories, tar will not know if any glob was entered, nor what the values of those globs were. So, it sees file1, file2. Then it sees file1 file3. `tar` has no idea whether file2 was removed or just did not match any glob pattern, or was intentionally omitted. Thus, it'd be impossible to know whether to delete it from the target, and the behaviour is entirely expected. Damn, you led me right up to the water and I stared at it thinking, "I'm thirsty, got anything to drink" for quite some time. Duh. Probably should be stated in the docs for incremental backups the implications of passing directories vs files though. I'm calling it a mild bug in the docs, and may file an issue. Possibly `tar` itself could issue a warning when --incremental and parameters are files, not folders. Thanks Alvin! I got there eventually.