Re: dar complains when creating decremental backup

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/08/2019 10:33, Matus UHLAR - fantomas wrote:
>>> On 04.08.19 21:01, Denis Corbin wrote:
>>>> looking at source code, this message is issued if the file
>>>> "to be added" (from -@ archive) has no EA or no FSA while the
>>>> one "in place" (from -A archive) has some EA or FSA
>>>> respectively.
> 
>> On 25/08/2019 16:02, Matus UHLAR - fantomas wrote:
>>> could it be that this message is issued when file "to be added"
>>> has no EA or FSA, even when the file in archive also does not?
> 
> On 26.08.19 19:33, Denis Corbin wrote:
>> Normally no, the archive you've created as you show below
>> contains FSA
> 
> but none of them contains EA.
> 
> what you said above can mean that if there's "no EA or no FSA" in
> archive but file in place "has EA or FSA".
> 
> If the logic is implemented like this, both conditions are true,
> because file in archive no EA (first condition) and file on
> filesystem has FSA (second condition), thus warning is issued.
> 
> Looking at the source I can't quickly decide if this is the issue. 
> (I understand C/C++ but am not a programmer and it takes time for
> me to understand code)
> 
> can you please look if I got it right?
> 

back to the source of your request and to the source code :)

while merging archives, which include building a decremental backup,
[see src/libdar/filtre.cpp routine filtre_merge_step1()], if a file is
present in both archives, the overwriting policy is used and returns
two decisions:
- - it decides from which file to take data from [act_data]
- - it decides from which file to take EA *and* FSA from [act_ea]

Why EA and FSA are considered as a whole (while they are independent)
is due to the fact that any EA change as well as any FSA change
modifies the ctime of the inode. no way to know whether the EA only
changed or whether FSA only changed (or both changed).

In particular when the policy has to decide to keep the more recent
attribute, it cannot distinguish between EA and FSA.

Given the return from the overwriting policy decision, the
filtre_merge_step1() routing fetches the data from the requested file
and the EA+FSA from the requested other/same one, issuing a warning
when it comes to "overwrite" data or another message when it comes to
"overwrite" FSA+EA

this second message does not make distinction whether there is EA
only, FSA only or both EA and FSA, the result is that the EA+FSA of
the file 'to be added' will replace those of the 'in place' file,
which may lead to either remove EA, FSA, or both of them, if
respectively the file 'to be added' has no EA or no FSA or none of them.

So by overwriting "EA and FSA" it means replacing them by the status
they have in another file may they be present or absent.

Just hope this explanation brings some clarifications!

for more details about overwriting policy read also the man page about
the -/ option, it should help having a global picture of what it does
and how it works.

Cheers,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl1lcdsACgkQCDGwvQPY
sYI5sA/+JMvqIHTiWQpMX5edOo7Rf4DrMcbfv2RkP+MpYdd05al0Xutwp1EgU8ij
NHZep2oK1CNNdFKDnl1BlY3yCrPfDT5fm70Le9+6YW5HIeYHEEUJl8/5UeqTAl1T
ARgoVUYq21n/lMu2KWmrrm86auVep4IoHJGxM/YHW3rbAlBbkk2vV8iwzuSvgbD/
pWWbPSRy0//uKAmoVJtBPFv8yV1mhoPyRGXl/T3T7bxi0cYG8zaJdTwEOED9tYhi
FH/EPHyxikzjlMrMEF9RKOq9Lw9eQeOJE4tLRmfq7RR+HL+kdrK6t/7ABjdAl/ul
AKQPaMg1m3wGfexJpUkuTaGsIyOFHybygMyXovj1JFFqQyTA/0Zz13yaIFoFEvFR
iUSp5f2hCPPBAVYVdpjRF6BGcF/dj4L8RBSECPx/TeREsIggIG4lmQDomOY8PXWU
BWAT8h/Y5shN0ldl10baLdIq/xuTQHgY7XYV7dmnZY4LKm049j9dgZCNZrnmEv9T
R/cRP9nwVbSbPxzidb57ZkcHCrAME2OBDW8jGrgQshIviEn21heDYJnKvVw1hb2h
pA7+tyriHbAt0i+3KV8Bxzdc5CbhleETeXkn3IlIyZkhT2+TJzexbmXz/JIU5QCY
ZNpxcHk8yHswpCWZgYabahvfKczC5+5LEWwLQIvG9KpiMjh7v7A=
=XtKC
-----END PGP SIGNATURE-----