folder compare - file sync - time stamp - win7/BC3.1.11

[bobchap]

I have recently encountered a very strange problem involving the resulting target time stamp on a very specific type of file using file sync. The files are several to many years old, and are part of a Quicken archive set accumulated over many years. The files involved are _ALL_ .eml files (text email threads from CheckFree) of 18K to 21K bytes (typically 18,526 or 20,072). They represent about 20% of the files copied, and many but not of all of these files seem to be affected -- typically 144 or 145 files but some times as many as 244 files.

The files affected are all copied correctly but the target time stamp is set to the (current) copy time rather than the original time stamp. Solution procedure is: (a) do a folder compare, (b) display only mis-compares ignoring folder structure, (c) select all and do a binary compare showing that all files are identical, (d) repeat steps (a) and (b) and use touch to correct the time stamps of the target files.

Failure is VERY repeatable. System is Win7 Ultimate x64 with BC 3.1.11. Drives involved (3) are all 2TB SATA, one attached to MOBO and two attached to an add-in card.

I have been a user of BC for backup/archive purposes for many years and this really shakes my confidence. I hope someone can explain the problem and/or fix it.

[Aaron]

Hello,

This can sometimes happen when a remote drive does not allow us to set the timestamp during the copy, or an FTP denies permission, but this would be the first time I've heard of it on a local drive.

Are you able to repeat the issue if you copy from one test folder to another on the primary MOBO harddrive? If you perform the copy with My Computer instead of BC3, are you able to reproduce the issue as well?

[bobchap]

There are a total of 699 of the .eml files in the archive folder in question. This archive folder contains 11,985 folders and 127,925 files with approximately 91GB of data. The three drives in question contain approximately 1.5TB of data contained in "root" folders of 25-200GB each. I'll call these drives E: (working), H: (backup#1), and V: (backup#2). Some of the date on E: is not backed up. All of the date from E: is backed up to a folder on the backup drives called "Drive-E". The backup drives also contain data not found on E:, so the archive folder with the .eml files is at a different level on the backup drives than on the working drive.

I first discovered this problem while attempting to create V: and synchronize E:, H:, and V:. So far, I have detected no time stamp errors on any non .eml files, and the number of incorrect time stamps has been between 144 and approximately 250 (of the total of 699 files).

I have begun using folder compare/file sync operations on test archive folders on all three drives and have not yet reproduced the timestamp error. So far, the tests have involved syncing only the 699 .eml files on the original archive on E: to test archives on backups H: and V:. I will continue testing, syncing the entire 91GB amoung the three drives, and will also contiune building the backup set on V:. I'll let you know of any additional errors.

Thanks for your efforts,
bobchap

[Aaron]

Hello,

One other test to consider would be to cut your task into subtasks. Only sync and compare sections of your 91 gigs at a time. This can help you limit the number of files to review and will help narrow down if the size of the comparison is the issue or if the file type is the issue.

[bobchap]

Hello,

One other test to consider would be to cut your task into subtasks. Only sync and compare sections of your 91 gigs at a time. This can help you limit the number of files to review and will help narrow down if the size of the comparison is the issue or if the file type is the issue.

Acutally, for the first tests I performed (after my initial post) with the "artificial" archives, I EXCLUDEd all folders except those containing .eml files. I then filtered the resulting folders to show only the .eml files. Result: sync (meaning "sync selected" with only .eml files selected) with no timestamp errors.

For the second set of tests (still "artificial" archives) I EXCLUDEd the four largest folders not containing .eml files. This eliminated 9700 folders and 112,000 files, accounting for 43GB of data. Result: sync with no timestamp errors.

For subsequent testing I will copy subsets or full sets of unfiltered data and check the resulting .eml timestamps. My original discoveries were based on full archive sets (all 91GB copied) containing .eml timestamp errors. After I discovered the errors I used a *.eml filter with only files with differences displalyed to touch only the files with the errors, but additional full 91GB syncs produced more .eml timestamp errors.

Regards,
bobchap