Re: MAYBE BUG in dar 2.7.2 with hardlinks handling

On 04.12.2021 20:39, Denis Corbin wrote:
> I'm not sure to follow what you plan to do, but I guess it is
> possible...

Based on your answers I guess that you are probably missing the main
point of "my plan" here. Idea was to introduce a new mode of "filesystem
traversal" for which we totally get rid of real FS traversing and
instead get the list of files to work with from some "external source".
Then we apply filters in usual manner based on include/exclude rules,
e.t.c., e.t.c.

Expected use pattern would look like this:
# find <backup root dir> <filtering options> | sort -u >
file-list-to-include-into-backup.txt
# dar -R <backup root dir> --files-to-consider-list
file-list-to-include-into-backup.txt -c <new backup name> -A <previous
backup> .....

This way user would be in the full control of the ordering of files to
backup thus it would be possible to make sure that files from "older"
subdirectory would come in front of files from "new" subdir when applied
to my failing use case described in earlier message.

> I tried playing with the merging operation ... If the new backup do
> not contain the old hardlinked inodes, at restoration time, the hard
> links may not be restored (the hard link is missing in the restored
> directory): this is because the order in which the directory content
> was returned by the operating system is kept in the backup...

Tried to do the same and observation is that for hardlink to be restored
two conditions should be met:
1. Target file to hardlink to should exist.
2. Archive entry pointing to the target file to be hardlinked to (i.e.
one that is not "[Saved]" and is inside a dir that is not "[Saved]" too)
should come before any other entry which is a hardlink to the same inode
residing in a dir that is "[Saved]".

Let me illustrate with an example. Given is that we have file named
"79/abc.txt" in place on the disk. Then with archive looking like this:

[Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
--------------------------------+------------+-------+-------+---------+-------------------------------+------------
[     ][-]       [---][     ][ ]  drwxr-xr-x   root     root    0       Fri Dec  3 02:14:30 2021        79
[     ][ ]       [---][-----][ ] *-rw-r--r--   root     root    15 kio  Fri Dec  3 02:14:30 2021        79/abc.txt [0]
[Saved][-]       [---][     ][ ]  drwxr-xr-x   root     root    0       Fri Dec  3 02:14:30 2021        80
[     ][ ]       [---][-----][ ] *-rw-r--r--   root     root    15 kio  Fri Dec  3 02:14:30 2021        80/abc.txt [0]

... hardlink 80/abc.txt will be restored.

But in case the archive lists like this:

[Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
--------------------------------+------------+-------+-------+---------+-------------------------------+------------
[Saved][-]       [---][     ][ ]  drwxr-xr-x   root     root    0       Fri Dec  3 02:14:30 2021        80
[     ][ ]       [---][-----][ ] *-rw-r--r--   root     root    15 kio  Fri Dec  3 02:14:30 2021        80/abc.txt [0]
[     ][-]       [---][     ][ ]  drwxr-xr-x   root     root    0       Fri Dec  3 02:14:30 2021        79
[     ][ ]       [---][-----][ ] *-rw-r--r--   root     root    15 kio  Fri Dec  3 02:14:30 2021        79/abc.txt [0]

... then hardlink won't be restored.

In your experiments at least one or both of conditions listed above were
not met due to the ordering of the entries in the archive which was
determined by the initial ordering at creation time matching the order
filesystem traversal was done by the OS. It won't be the case for "
filelist-based backup approach" described above as entry order would be
warranted to be predictable and stable thanks to manual efforts taken to
sort (and manipulate in any other way required) the list of
files/directories to be backed up.

-- 
Regards,
Alexey Loukianov
System Engineer
*nix Expert