Script not overwriting files

[PeteM]

I've got a batch file that runs overnight to backup files to my NAS drive, it works fine for new files but if I change a file on my PC it does not do the copy over the top of the old version. The command line I am running in the batch file is:-

"C:\Program Files\Beyond Compare 4\BCompare.exe" @"Pete.txt" /closescript

The instruction file contents is-
=====
log normal "Logs\Pete.log"
load "NAS-Pete"
option confirm:yes-to-all
sync create-empty update:left->right
=====

If is run NAS-Pete in Beyond Compare it finds the files that have changed, if I then tell it to copy right it asks me if it is OK to overwrite and when I confirm does the copy. I am running version 4.4.0 build 25886.

Can anyone see what I am doing wrong?

TIA

[Aaron]

Hello,

When it finds the files have changed in the interface, what is their comparison status? When prompting to ask for an overwrite, that usually means the destination files have a read-only flag or are Newer in status.

Which command are you using to perform the "copy" in the interface? Is it literally the Copy command? Or the Actions menu -> Synchronize -> Update (left to) Right.

Option confirm yes to all in script should resolve this if it were read-only. What color are the files in the interface, and what are their timestamps/size, etc?

[PeteM]

Hi

Files are marked as no match and coloured red. The only flags on either files is the archive bit.

I've been using the right click then "Copy to Right" which works as expected but when I try Actions menu -> Synchronize -> Update (left to) Right it tells me "Nothing to do!" which is weird as the file I am using to test is 120 bytes on the PC and 114 on the NAS, it is a small text file that I have added two characters to the end of on the PC.

Date stamps are 23/09/2021 19:14:08 on the PC and 23/09/2021 10:49:25 on the NAS box so they are showing correctly.

I've just used the right click menu to copy right and the file on the NAS is now 118 bytes so it appears to have shrunk two bytes, making a further change and the action menu now works. The files are straight forward ascii and the reported lengths are logical in that they are one byte per character plus two bytes for each CRF/LF (it is actually the instruction file quoted in the opening post).

[Aaron]

Files that are Red <> Grey or Grey <> Red are Newer <> Older or Older <> Newer status. The Sync Update command would only copy from Source to Destination if the Source is Red(Newer), overwriting an Older file. If files are both Red, then they are "Different" status, which means the content or size is different, but they have equal timestamps; because this is an odd case this requires manual review.

It sounds like this should show as
PC to NAS
Red to Grey

What confirmation message are you seeing, exactly, when you run this in the interface, and is that coloring a correct assumption when viewed in the interface? We should be able to get that working first, and then move back to the script.

When using the interface, you have to either select the item before issuing the script, or have "just selection" disabled in the Sync Update dialog pop-up. For script, this isn't necessary (Just Selection is always disabled) so the script itself looks right to me, but the confirmation box is odd, and we do want to double check the coloring when loading the Session Name. If the session's Session Settings, Comparison tab, Timestamp has been disabled, then both sides would be red and Update would not copy them.

[PeteM]

Hi Arron

For reference the comparison options are:

• Compare file size
• Compare filename case
• Compare contents - CRC comparison, Skip if quick tests etc.

I don't have timestamps ticked as it was giving me a huge amount of false positives.

I am getting the files showing as red to red, like this:



Confirmation message (from action menu) is as below, I had selected the left hand Pictures.txt file prior to requesting the Update Right:

[Aaron]

Thanks for the screenshots. That confirms what I was thinking. You have timestamps Disabled as a comparison criteria, while still showing the column as visible. Without timestamp as a criteria, neither file can have the concept of 'Newer' and a Sync Update only works with Newer items. Your files are Red on both sides

You have to enable the Session Settings, Comparison, enable Timestamps. CRC with Override Quick Test would override that difference if they are the same, but this allows the timestamp to impact the sync logic.

[PeteM]

Thanks for that, at least we know what the issue is now.

Is there a way around the false positives? I know when BC copies a file it maintains the timestamp so the problem will eventually resolve itself but if I can avoid going down that route I would prefer it.

[Aaron]

Sorry, I'm unsure of what you mean by "false positive". Assuming the timestamp setting is disabled, then it is working as configured.

My suggest is to update the Session that the script is loading, in the interface, so that it also has timestamps as a concept enabled. This should update the comparison pane so they are red/grey instead, which would allow the Update logic to copy the Newer over the Older.

The file above is Different (in content, as the center column shows a content scan difference), but because timestamp is disabled, that acts the same as if the timestamp were equal but content different. A Sync Update won't automatically overwrite one side over the other, since we don't know which is Newer (in this case, because timestamp was disabled as a criteria). Sync Update only copies "Newer" status files, and with timestamp disable, no file can have this status assigned.

[PeteM]

False positive: when BC logs a difference just because the time stamps are different, so it is reporting a difference when there is none.

What I want is, if the content is different to always copy the left hand side to the right hand side irrespective of the timestamps.

[Aaron]

Override Quick Tests option would handle that scenario. The timestamps would be different, but the Content scan (center column between files) would determine if the files are actually equal or not. In the above, they are different. If that were equal, it would Override the Quick Tests (timestamp/size) and the status would be equal/black coloring.

You could also use a combination of select left.different.files and manually copying that selection, but I'd suggest testing different comparison criteria first to see if we can get the comparison to return equal when you believe they should be equal and different/newer when they are different and should be copied.