Indication of overwriting newer files

[ChrisZ16]

I have been using Zaloha2 for some time now and it helped me a lot - thank you for this great script!

With Zaloha2.sh (v2022-01-08) on Linux Mint 20.3 the warnings before overwriting newer files are not what I expected:

Check in one direction:

TO BE COPIED TO /media/windows_D/winword/

unl.UP    Text/Mat/bib/034.pdf    => correct, newer file
unl.UP.!  Text/uni.docx       => correct, newer file
unl.UP.!  Text/NO_69b/69b.odt     => would overwrite newer file
UPDATE.!  steuer/2022.odt     => would overwrite newer file

Check in reverse direction:

TO BE COPIED TO /media/freenas/work/winword/

UPDATE.!  Text/Mat/bib/034.pdf    => would overwrite newer file
UPDATE.!  Text/uni.docx       => would overwrite newer file
UPDATE    Text/NO_69b/69b.odt     => correct, newer file
UPDATE    steuer/2022.odt     => correct, newer file

Shouldn't it show "UPDATE.?" or "unl.UP.?" (with question mark) before overwriting a newer file? The exclamation mark ("!") did not seem dangerous to me ("newer than last run of Zaloha"), but actually it was.

Has this to do with

• windows_D being a Windows NTFS disk (mounted via fuseblk)
• freenas being a NAS, mounted via cifs?

Time differences between old and new files were several hours (more than 3600 secs).

Why is it sometimes "UPDATE.!" and sometimes "unl.UP.!" - the files to overwrite are on the same drive? I noticed this difference only, when the target files are on the NTFS-disk

The command was:

./Zaloha2.sh --sourceDir="/media/windows_D/winword" --backupDir="/media/freenas/work/winword" --color --findSourceOps='( -type f -a -iname ~$Normal.dotm ) -o' --findGeneralOps='( -type d -a -name Zaloha_metadata ) -prune -o' --findGeneralOps='( -type f -a -iname *.wbk ) -o' --noRestore --mawk --noProgress --extraTouch

and same in the opposite direction.

Thank you!

[Fitus]

Hello,

overwriting a file that is newer than the last run of Zaloha (= UPDATE.!) should actually be the maximum alert, because this (for almost sure) means that the copy target has been modified since the last run of Zaloha and those changes would be lost.

From your data I made following picture about the file modification times:

Assume last run of Zaloha = 12:00

	on freenas	on windows_D
034.pdf	15:00	09:00
uni.docx	15:00	16:00
69b.odt	09:00	16:00
2022.odt	09:00	16:00

The UPDATE.? would come in following situation (again assume last run = 12:00):

	on freenas	on windows_D
034.pdf	10:00	09:00

I can't say whether your issue contains a component caused by your specific HW setup. If you are in doubt, look into metadata file 370_union_s_diff.csv for what modification times (column 5) are reported there for your files.

Last run of Zaloha is in file 300_lastrun.csv.

Ad difference between UPDATE and unl.UP: unl.UP means that the target file is multiply linked, also it is not good to simply overwrite it: it must be removed first, then created again. It is described in the docu BTW.

Best regards, F.

[ChrisZ16]

Thank you for your detailed explanation! Now I understand it better.

I use Zaloha2 to copy from my PC to my NAS, then work on another PC with data on the NAS and when ready, go back to the first PC and from there copy back. Of course I normally do not change data on the first PC after having copied and changed them on the NAS. My question above was a case where I forgot that and did make such changes (no damage done, I checked Zalohas messages carefully).

My PC and NAS each have a .Zaloha_metadata directory (per target directory). So the "newer than last run of Zaloha" exclamation mark probably does not indicate what it is meant for, because there are two different "last runs of Zaloha", each for one direction. Nevertheless it works perfectly, if I leave the files untouched on the first machine between copy and copy back.

Should I use only one .Zaloha_metadata directory (on the NAS, where both PC can write to)? If yes, how do I do that?

Ad unl.UP means that the target file is multiply linked: I did not set any links. Maybe this has to do with the file being on a Windows NTFS disk mounted in Linux, since I notice it only in this case.

Thank you and Best Regards Chris

[Fitus]

Hi,

good point! In your setup you have two "last runs", one for each direction!

So you synchronize PC --> NAS, edit on NAS, synchronize NAS --> PC, edit on PC, and now: when you synchronize PC --> NAS again, the file on NAS is newer than the last run of PC --> NAS, and you get UPDATE.!

So you get unnecessary UPDATE.!

So you got used to them and considered them as "less important". You clearly need one "last run". The last run is the modification time of file 999 in .Zaloha_metadata directory.

A possible solution would be to have only one .Zaloha_metadata directory, let's say the one on NAS. Also in the NAS --> PC synchro, tell Zaloha to use the metadata directory on NAS and not the default one on PC:

--sourceDir="/media/freenas/work/winword" --backupDir="/media/windows_D/winword" --metaDir="/media/freenas/work/winword/.Zaloha_metadata"

If you specify the meta directory explicitly, you also have to exclude it explicitly, also add findGeneralOps:

--findGeneralOps="-path ///d/.Zaloha_metadata -prune -o"

Ad multiply linked: Hard to say why FIND reports the files as multiply linked (column 9, which is -printf '%n'). It might be some undisclosed technical feature of the machine which hosts the NTFS volume. Try stat on one of the files. What link count does it report?

Please leave this issue open, as a docu of this interesting use case.

BR F.