How does BC created Modified Timestamp of Folders in Folders Compare?

[ScoobyDoo]

Hi,
i did a folders compare today with a backupdestination and got the following result, where it showed the "Modified" Timestamp for the Folder "Media eigen" with:
a timestamp of "17.09.2020 15:38..."

But Windows shows me for the modified timestamp:


the right side is the backup location, which shows (except the 1h difference) the same timestamp for the folder as windows (i use robocopy for Backup and preserve the timestamps for folders).

in the help (under 'how to compare folders') i found this :

Generally, these criteria are used to compare files, and not folders directly. For instance, a folder's timestamp does not affect the comparison. A folder is classified as "newer" if it contains newer files. Folders are compared by aggregating the comparisons of files within them.

This leads me to 2 questions:

1. If i understand the help correctly no folders timestamp does ever affect a comparison at all? BC only takes "modified" timestamps from files into consideration.
2. But then i still struggle to understand where does the shown modified timestamp of 17.09.2020 15:38:20" come from?
   There is no filter, so all files that are different are shown and the only different file is this temporary system file "~$rgleich.... But the timestamp of that file is neither from yesterday?

So i would really like to understand this more in detail any help appreciated!

the settings for the comparison where:

Greetings!

[Aaron]

Hello,

The Folder's displayed Modified Timestamp is the metadata of that folder, and should match what you see in Explorer or if you right-click -> Properties on that folder. We display the metadata in the columns, but it isn't included in the Comparison status of those items. Folder coloring is inherited by the content within them, not the folder's timestamp itself. This way, at a glance, you can find differences; otherwise you would have scenarios where the folder could show as if it were equal, but have different files inside, or the reverse.

I'd suggest a quick reboot of the computer to clear any odd caching, and if either side is a network device cycling that quick, and then re-verify all 3 reports of the timestamp. Robocopy is usually good at preserving timestamps, but some destination devices will still set them to the time of the transfer. The expectation is it should report the Last Modified timestamp (in Properties) equally for each application.

Also, folder timestamps are not very reliable, which is part of why BC4 does not compare them. For example, if you copy using a program like BC4 or Explorer, the timestamp is initially preserved, until the moment another file copies into that folder (even as part of the same transfer), which then updates it.

The Touch command can override the Last Modified of any selected items (include a selection of folders), but it is also pretty easy for something external of BC4 to then update those folder timestamps.

[ScoobyDoo]

Hi Aaron,
thx for that answer. Unfortunately a reboot did not solve the discrepancy between the timestamp shown in BC and the Windows timestamp. In Win7 one does not get the "modified timestamp" with a rightclick on the folder only the "created" timestamp is shown in properties (crazy i know). The only way to find this info is by going into the parent folder there it is shown:

BC still shows the 17.09.2020.

Btw this is the left folder of the comparison its on my machine so no copying to a server. (the right side is a backup-drive connected via usb so no server neither). As yesterday Freecommander shows it like windows (besides 1h):


you wrote:

Also, folder timestamps are not very reliable, which is part of why BC4 does not compare them.

actually i am using final version 3 on a win7 64-bit machine, might this be a bug in BC3 or was it handled differently in that version?

Have a good one!
Frank

[Zoë]

Try turning off "Automatically scan subfolders in background" and "Expand subfolders when loading session" in the Session settings Handling tab, then restart BC and reload the comparison. Does the folder's timestamp change when you manually expand it? The other way to check this would be to use the command line console (cmd.exe), go to F:\NormalVer, and do a "dir" to get the timestamp for "Media eigen", then change into that subdirectory, do a "dir" again" and see what the timestamp is for the '.' entry.

I only remember this coming up once before, a long time ago, so I could be getting it wrong, but I believe some filesystems keep separate entries representing a directory, one in the parent folder and one for the '.' entry pointing to itself. Generally those will always match, but if they somehow get out of sync, it will show the behavior you're seeing. BC uses the timestamp from the parent folder when it's populating the base folder, but when it's reads the subfolder's contents it also uses the '.' entry to update the folder's timestamp. Explorer never displays a folder and its parent together, so it's only going to use the timestamp as stored in the parent folder.

[ScoobyDoo]

Try turning off "Automatically scan subfolders in background" and "Expand subfolders when loading session" in the Session settings Handling tab, then restart BC and reload the comparison. Does the folder's timestamp change when you manually expand it?

Yes when i turn this off. It first shows for "Media eigen" the correct date of 24.03.2015. then when i expand it it changes to the wrong date 17.9.2020....

in the commandline it shows 24.3.2015 which is not surprising since windows shows sthis timestamp.
I never thought about the "." What does this stand for? The date shown there is the same as for ".." and is the 17.09.2020.

speaking of filesystem. The filesystem of F is a Truecrypt Container so its "FAT32".

One Question i would like to have really confirmed is this: In folder compare when either file size OR timestamp differs the file will be shown as different right? And the folder will be colored.

Greetings..

[Aaron]

Hello,

The Session Settings control how the comparison works. By default, if either timestamp or size are different then the file will be marked as a difference (Newer, Older, or Different (not newer or older, but different size/content) status). This is just for files, and the folder coloring inherits the file comparison status within it. You can View menu -> Legend to see how folder coloring generates.

Are there any folders on your Win7 computer that aren't under the control of Truecrypt? Are there any folders that don't exhibit this issue of different metadata timestamps (either under Truecrypt or not under Truecrypt), to try and determine why this timestamp diverged when it should be the same?

[ScoobyDoo]

Hi Aaron,
quickly i can not come up with more folders that do differ.
Zoe was asking pretty specific questions, i thought she knows more about this and witht the answers i gave xould tell me more.
If not- no problem. I actually already spent to much time with this and should go on

Have a good one

[Aaron]

The answer helps confirm the issue, that the file system has two different Last Modified timestamps for the same item (one stored with the parent of the item, one stored with the item itself). They're supposed to be the same and we don't have a test environment or know what can cause this behavior. My question was to try and limit to what on your system might have caused it; if it's system wide, specific to TrueCrypt control, or anything else about your folders that I might be able to recreate it with. BC4 assumes the timestamp values are the same and pulls from either location assuming they are (and should be) equal. Zoe remembers this happening to one other customer, but we were never able to track down how their system had gotten the two representations of the same timestamp out of sync.

If size is a another marker, your files would be marked as different with any size difference. You can also enable (a slower) Binary content scan, which would confirm if the files are exact copies of each other regardless of the timestamp, and would detect any changes even if the file size were the same.

[ScoobyDoo]

Hi,
my best guess is its a problem with the TrueCrypt Container (i am using version 7.1.a since that is the last "trusted" version by most people |with a contianer).
Since TC acts as a driver there can be differences one would not have on a "real" FAT32 volume.

If size is a another marker, your files would be marked as different with any size difference. You can also enable (a slower) Binary content scan, which would confirm if the files are exact copies of each other regardless of the timestamp, and would detect any changes even if the file size were the same.

I got a bit confused by this. What i wanted to ask is this. if i have the default options on - so both boxes checked:


Does ist always compare File size AND timestamp of the files?
Let's say i check 3 boxes: size,file timestamp AND "filename case" in which order would the comparison goe through
If filesize and file timestamp woudl be the same would it still compare "filename case"?
Or is it using some kind of logic like that it compares files sizes (which i assume is much faster) and only in cases of doubt timestamps?
I am asking this because it nowhere states this in the help what happens when you check several options...

greetings

[Aaron]

Hello,

Out of the box factory defaults, File size and timestamp are enabled, although defaults can be updated to some other combination by the user for any future new sessions.

File comparison status (View menu -> Legend) can mark files as Same, Newer, Older, Different, or Orphan. The combinations determine the status, so a file that has a newer timestamp and size differences is "Newer", or a file that has a different timestamp and the same size is still "Newer". "Different" is only used (both files are red) when the timestamp is the same but the size/content is different, which is an odd state since how was the file modified without updating the last modified timestamp.

If you also enable file name case, then if Timestamp, Size, or Filename case are different, the file will be marked as Different (or Newer if timestamp is also updated).

The bottom option of "Override Quick Test results" can overwrite the timestamp/size/etc differences in the Quick Tests area of that dialog, but only with a detailed content scan, such as a Binary scan determining if the files are equal even if the timestamp reports it as different, that would mark as equal.

[Aaron]

If truecrypt is desyncing these file system timestamps (all external of BC), that isn't something we'll be able to address. The timestamps are supposed to be in sync, and that would be a bug to desync them.