tar: Potential bug (?) when incremental archive selected - Deleting files in the target
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have quite interesting observation which perhaps is a manifest of a bug.
My use case is to:
- take a backup of a folder, having a set of files from this folder added to --exclude-from file. I'm working with incremental backup (-g option set)
- on a new machine, restoring the tar to same location as on the original machine. Note, the new machine has already some files in the location; if anything exist, I want to replace / overwrite it.
Steps to reproduce
Create files and folders structure as below:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 1.cfg
âÂÂâÂÂâ 2.cfg
âÂÂâÂÂâ 3.cfgCreate exclude and include files
mbp:tarTests jhartman$ cat /tmp/include.cfg
/tmp/src/etc/
mbp:tarTests jhartman$ cat /tmp/exclude.cfg
/tmp/src/etc/config/*.cfgCreate an archive
$ rm -f /tmp/snapshot
$ tar -g /tmp/snapshot -cvz -f /tmp/test.tar.gz -X /tmp/exclude.cfg -T /tmp/include.cfg
./tar-1.27/src/tar: /tmp/src/etc: Directory is new
./tar-1.27/src/tar: /tmp/src/etc/config: Directory is new
./tar-1.27/src/tar: Removing leading `/' from member names
/tmp/src/etc/
/tmp/src/etc/config/
/tmp/src/etc/A.cfgUn-archive to a new server. Before unarchiving, files in the new server:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
âÂÂâÂÂâ 4.cfg
âÂÂâÂÂâ 5.cfgun-archive (on the target machine)
$TAR_BASE/src/tar --overwrite --extract --force-local --listed-incremental=/dev/null --file /tmp/test.tar.gz -v -C /
tmp/src/etc/
tmp/src/etc/config/
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/4.cfgâÂÂ
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/5.cfgâÂÂ
tmp/src/etc/A.cfg
So eventually, files in this folder:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
As you see, despite 4.cfg
and 5.cfg
were not int he src machine, they are gone. I'm guessing it's because of using /tmp/src/etc/config/*.cfg
in the exclude file.
Worth to mention that this behaviour was changing across the versions: 1.30, 1.27, 1.27.1, 1.29 - NOK, 1.25, 1.26, 1.28 - OK (where NOK means - I could see Deleting message for the files in my concern).
What do you think?
Thank you,
Jarek
Update, 2018-08-21, 20:51
Regardless of the version I run, output of the --list
operation is same and shows D at the config
folder:
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/
Y A.cfg
D config
drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/
N 1.cfg
N 2.cfg
N 3.cfg
-rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg
Update 21:03
For reference, scripts I've used for the tests are stored in https://github.com/jaroslawhartman/tar-tests repo.
See output.txt
for detailed results of the tests.
linux tar gzip archive
 |Â
show 1 more comment
up vote
1
down vote
favorite
I have quite interesting observation which perhaps is a manifest of a bug.
My use case is to:
- take a backup of a folder, having a set of files from this folder added to --exclude-from file. I'm working with incremental backup (-g option set)
- on a new machine, restoring the tar to same location as on the original machine. Note, the new machine has already some files in the location; if anything exist, I want to replace / overwrite it.
Steps to reproduce
Create files and folders structure as below:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 1.cfg
âÂÂâÂÂâ 2.cfg
âÂÂâÂÂâ 3.cfgCreate exclude and include files
mbp:tarTests jhartman$ cat /tmp/include.cfg
/tmp/src/etc/
mbp:tarTests jhartman$ cat /tmp/exclude.cfg
/tmp/src/etc/config/*.cfgCreate an archive
$ rm -f /tmp/snapshot
$ tar -g /tmp/snapshot -cvz -f /tmp/test.tar.gz -X /tmp/exclude.cfg -T /tmp/include.cfg
./tar-1.27/src/tar: /tmp/src/etc: Directory is new
./tar-1.27/src/tar: /tmp/src/etc/config: Directory is new
./tar-1.27/src/tar: Removing leading `/' from member names
/tmp/src/etc/
/tmp/src/etc/config/
/tmp/src/etc/A.cfgUn-archive to a new server. Before unarchiving, files in the new server:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
âÂÂâÂÂâ 4.cfg
âÂÂâÂÂâ 5.cfgun-archive (on the target machine)
$TAR_BASE/src/tar --overwrite --extract --force-local --listed-incremental=/dev/null --file /tmp/test.tar.gz -v -C /
tmp/src/etc/
tmp/src/etc/config/
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/4.cfgâÂÂ
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/5.cfgâÂÂ
tmp/src/etc/A.cfg
So eventually, files in this folder:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
As you see, despite 4.cfg
and 5.cfg
were not int he src machine, they are gone. I'm guessing it's because of using /tmp/src/etc/config/*.cfg
in the exclude file.
Worth to mention that this behaviour was changing across the versions: 1.30, 1.27, 1.27.1, 1.29 - NOK, 1.25, 1.26, 1.28 - OK (where NOK means - I could see Deleting message for the files in my concern).
What do you think?
Thank you,
Jarek
Update, 2018-08-21, 20:51
Regardless of the version I run, output of the --list
operation is same and shows D at the config
folder:
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/
Y A.cfg
D config
drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/
N 1.cfg
N 2.cfg
N 3.cfg
-rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg
Update 21:03
For reference, scripts I've used for the tests are stored in https://github.com/jaroslawhartman/tar-tests repo.
See output.txt
for detailed results of the tests.
linux tar gzip archive
Do you see differences in the output oftar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions oftar
? (E.g. with 1.29 I seeconfig
being listed as deleted.)
â Stephen Kitt
Aug 21 at 15:58
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have quite interesting observation which perhaps is a manifest of a bug.
My use case is to:
- take a backup of a folder, having a set of files from this folder added to --exclude-from file. I'm working with incremental backup (-g option set)
- on a new machine, restoring the tar to same location as on the original machine. Note, the new machine has already some files in the location; if anything exist, I want to replace / overwrite it.
Steps to reproduce
Create files and folders structure as below:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 1.cfg
âÂÂâÂÂâ 2.cfg
âÂÂâÂÂâ 3.cfgCreate exclude and include files
mbp:tarTests jhartman$ cat /tmp/include.cfg
/tmp/src/etc/
mbp:tarTests jhartman$ cat /tmp/exclude.cfg
/tmp/src/etc/config/*.cfgCreate an archive
$ rm -f /tmp/snapshot
$ tar -g /tmp/snapshot -cvz -f /tmp/test.tar.gz -X /tmp/exclude.cfg -T /tmp/include.cfg
./tar-1.27/src/tar: /tmp/src/etc: Directory is new
./tar-1.27/src/tar: /tmp/src/etc/config: Directory is new
./tar-1.27/src/tar: Removing leading `/' from member names
/tmp/src/etc/
/tmp/src/etc/config/
/tmp/src/etc/A.cfgUn-archive to a new server. Before unarchiving, files in the new server:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
âÂÂâÂÂâ 4.cfg
âÂÂâÂÂâ 5.cfgun-archive (on the target machine)
$TAR_BASE/src/tar --overwrite --extract --force-local --listed-incremental=/dev/null --file /tmp/test.tar.gz -v -C /
tmp/src/etc/
tmp/src/etc/config/
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/4.cfgâÂÂ
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/5.cfgâÂÂ
tmp/src/etc/A.cfg
So eventually, files in this folder:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
As you see, despite 4.cfg
and 5.cfg
were not int he src machine, they are gone. I'm guessing it's because of using /tmp/src/etc/config/*.cfg
in the exclude file.
Worth to mention that this behaviour was changing across the versions: 1.30, 1.27, 1.27.1, 1.29 - NOK, 1.25, 1.26, 1.28 - OK (where NOK means - I could see Deleting message for the files in my concern).
What do you think?
Thank you,
Jarek
Update, 2018-08-21, 20:51
Regardless of the version I run, output of the --list
operation is same and shows D at the config
folder:
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/
Y A.cfg
D config
drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/
N 1.cfg
N 2.cfg
N 3.cfg
-rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg
Update 21:03
For reference, scripts I've used for the tests are stored in https://github.com/jaroslawhartman/tar-tests repo.
See output.txt
for detailed results of the tests.
linux tar gzip archive
I have quite interesting observation which perhaps is a manifest of a bug.
My use case is to:
- take a backup of a folder, having a set of files from this folder added to --exclude-from file. I'm working with incremental backup (-g option set)
- on a new machine, restoring the tar to same location as on the original machine. Note, the new machine has already some files in the location; if anything exist, I want to replace / overwrite it.
Steps to reproduce
Create files and folders structure as below:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 1.cfg
âÂÂâÂÂâ 2.cfg
âÂÂâÂÂâ 3.cfgCreate exclude and include files
mbp:tarTests jhartman$ cat /tmp/include.cfg
/tmp/src/etc/
mbp:tarTests jhartman$ cat /tmp/exclude.cfg
/tmp/src/etc/config/*.cfgCreate an archive
$ rm -f /tmp/snapshot
$ tar -g /tmp/snapshot -cvz -f /tmp/test.tar.gz -X /tmp/exclude.cfg -T /tmp/include.cfg
./tar-1.27/src/tar: /tmp/src/etc: Directory is new
./tar-1.27/src/tar: /tmp/src/etc/config: Directory is new
./tar-1.27/src/tar: Removing leading `/' from member names
/tmp/src/etc/
/tmp/src/etc/config/
/tmp/src/etc/A.cfgUn-archive to a new server. Before unarchiving, files in the new server:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
âÂÂâÂÂâ 4.cfg
âÂÂâÂÂâ 5.cfgun-archive (on the target machine)
$TAR_BASE/src/tar --overwrite --extract --force-local --listed-incremental=/dev/null --file /tmp/test.tar.gz -v -C /
tmp/src/etc/
tmp/src/etc/config/
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/4.cfgâÂÂ
./tar-1.30/src/tar: Deleting âÂÂtmp/src/etc/config/5.cfgâÂÂ
tmp/src/etc/A.cfg
So eventually, files in this folder:
/tmp/src
âÂÂâÂÂâ etc
âÂÂâÂÂâ A.cfg
âÂÂâÂÂâ config
âÂÂâÂÂâ 3.cfg
As you see, despite 4.cfg
and 5.cfg
were not int he src machine, they are gone. I'm guessing it's because of using /tmp/src/etc/config/*.cfg
in the exclude file.
Worth to mention that this behaviour was changing across the versions: 1.30, 1.27, 1.27.1, 1.29 - NOK, 1.25, 1.26, 1.28 - OK (where NOK means - I could see Deleting message for the files in my concern).
What do you think?
Thank you,
Jarek
Update, 2018-08-21, 20:51
Regardless of the version I run, output of the --list
operation is same and shows D at the config
folder:
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/
Y A.cfg
D config
drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/
N 1.cfg
N 2.cfg
N 3.cfg
-rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg
Update 21:03
For reference, scripts I've used for the tests are stored in https://github.com/jaroslawhartman/tar-tests repo.
See output.txt
for detailed results of the tests.
linux tar gzip archive
linux tar gzip archive
edited Aug 21 at 19:22
Kusalananda
107k14209329
107k14209329
asked Aug 21 at 15:28
Jarek
164
164
Do you see differences in the output oftar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions oftar
? (E.g. with 1.29 I seeconfig
being listed as deleted.)
â Stephen Kitt
Aug 21 at 15:58
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33
 |Â
show 1 more comment
Do you see differences in the output oftar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions oftar
? (E.g. with 1.29 I seeconfig
being listed as deleted.)
â Stephen Kitt
Aug 21 at 15:58
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33
Do you see differences in the output of
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions of tar
? (E.g. with 1.29 I see config
being listed as deleted.)â Stephen Kitt
Aug 21 at 15:58
Do you see differences in the output of
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions of tar
? (E.g. with 1.29 I see config
being listed as deleted.)â Stephen Kitt
Aug 21 at 15:58
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33
 |Â
show 1 more comment
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f463898%2ftar-potential-bug-when-incremental-archive-selected-deleting-files-in-the%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Do you see differences in the output of
tar --list --incremental --verbose --verbose --file /tmp/test.tar.gz
when you use different versions oftar
? (E.g. with 1.29 I seeconfig
being listed as deleted.)â Stephen Kitt
Aug 21 at 15:58
Hi, not really, no differences in this output. It's always D config, ----------------- TAR LIST drwxr-xr-x jhartman/staff 16 2018-08-21 20:44 tmp/src/etc/ Y A.cfg D config drwxr-xr-x jhartman/staff 22 2018-08-21 20:44 tmp/src/etc/config/ N 1.cfg N 2.cfg N 3.cfg -rw-r--r-- jhartman/staff 30 2018-08-21 20:44 tmp/src/etc/A.cfg -----------------
â Jarek
Aug 21 at 18:47
This is not about tar but about GNU tar. Note that GNU tar announced incremental backups in 1992 but incremental restores did never work for non-trivial cases even though there have been three related bug reports since 2004. You make things even more complex as you use exclude lists and as you in addition do not start with an empty target filesystem. Your expectations in this special case are subject of a discussion. I would be interested in such a discussion but this place does not seem to give the right base for such a discussion.
â schily
Aug 21 at 19:09
Hi Schily, I would agree that what I've observed is a "feature" if that was consistent across the versions. If this comes and goes across the version I tend to call it a bug or recurring regression. I also cannot call it "non-trivial" case... But perhaps I'm just irritated... Thanks!
â Jarek
Aug 21 at 19:57
This example unix.stackexchange.com/questions/411324/⦠is what I call non-trivial and this is still less complex than your problem.
â schily
Aug 21 at 20:33