Problems with DirSync with Diskinternals Reader in TC850

[gutberle]

Hi,

I am trying to rescue data of an ext3 drive that was part of a RAID1 set in an LG NAS system. All data on disk was in Windows SMB shares, so I am attempting to salvage them with a Windows system, but I have tried all available ext3 readers and generally speaking ext3 under Windows is a big, big mess...

As a notable exception the standalone Diskinternals Linux Reader does a good job salvaging the files and can deal with utf8 etc. quite well, but it does not allow for file/dir comparison for copy verification, so I was very relieved to see that there is a Diskinternals Reader TC plugin.

However, whenever I do a directory compare between a dir on my ext3 drive and the corresponding dir on my external USB (ntfs) drive, TC850 flags all files as different, despite identical (looking) time stamps, sizes, etc. When I then single out any two such "different" files for a direct left/right comparison, TC invariably says the contents are identical.

Is comparison between file system plugin data and native win data not possible in TC, or am I doing something wrong?

TIA,
gutberle

[ghisler(Author)]

It may be a problem with daylight saving time: It happens if you use a mix of NTFS and FAT(32) drives (or archives), because one system stores in universal time, and the other system in local time.

Solution: Please choose Configuration - Options - Operation - ignore 1 hour time delay.

Then Total Commander will ignore a time difference of exactly one hour.

[gutberle]

Thanks for the quick answer and suggestion. However, this is not it. But I now realize that I did not really describe accurately what is happening.

When I press "Compare" with "Subdirs", "by content", "ignore date" and "Empty directories" all enabled, all files and directories are read in, but as it seems, nothing is actually being compared "by content", since all files have the red question mark as the symbol after this comparison. If I disable "by content", then TC behaves as I expect it to.

Consequently, all files remain visible in the list when I only have the button for "Unequal files" AND also when I only have the button for "Equal files" pressed. As it seems TC does not (yet) know if they are equal...

Starting from this situation I can then select single files and actually compare them, again with the expected result of TC telling me they have equal content. However, this does not change the red question mark flag.

Am I making a mistake in operating TC here, or is there any other possible reason why "Compare by content" might fail to do so?

[ghisler(Author)]

What exactly are you comparing? Maybe one side isn't in the file system, e.g. accessed via FTP? TC doesn't support compare by content via FTP in the sync tool.

[gutberle]

One side of the comparison is a directory structure on an NTFS formatted drive. The other side is an ext3 formatted RAID1 drive connected to the PC via a SATA->USB bridge and accessed via the Diskinternals Reader plugin.

Both sides are therefore physically "local" and in a way both are "file system", but of course I do not know the innerds of the Diskinternals Reader and cannot say if the ext3 drive actually is "mounted" within TC850 and is therefore seen by TC as a true "local drive".

>> Also, as I wrote above, if I single out a given file and request a "Compare left&right" with Ctrl-F3, then the comparison by content is being done. Does this prove anything with regard to your question?

[ghisler(Author)]

Do both sides have a drive letter?

[gutberle]

Only the NTFS side has a drive letter. The Diskinternals side is given as "\\\DiskInternals Reader\Linux Ext Volume 4 (Raid 1 (Mirror))\*.*"

[ghisler(Author)]

I see - it sounds like the two files have different timestamps. Then TC will not compare by content, but just show the copy direction. It may be a time zone or daylight saving time problem.

[gutberle]

I singled out one file and got the exact time stamps for the linux/ext3 version from a linux box and for the Win7 version using powershell.

Linux:
root@partedmagic:/mnt/lgnas/DriveSnapshot# stat DriveSnapshot.log
File: ‘DriveSnapshot.log’
Size: 82432 Blocks: 176 IO Block: 4096 regular file
Device: 902h/2306d Inode: 19177479 Links: 1
Access: (0766/-rwxrw-rw-) Uid: ( 1001/ clamav) Gid: ( 100/ users)
Access: 2014-02-28 16:49:02.000000000 +0100
Modify: 2011-01-24 08:14:45.000000000 +0100
Change: 2011-05-05 11:15:41.000000000 +0200
Birth: -

Windows7:
PS L:\BS\D\DriveSnapshot> $file = .\DriveSnapshot.log
PS L:\BS\D\DriveSnapshot> $file = Get-Item .\DriveSnapshot.log
PS L:\BS\D\DriveSnapshot> $file.CreationTime
Donnerstag, 5. Mai 2011 11:15:41
PS L:\BS\D\DriveSnapshot> $file.LastAccessTime
Donnerstag, 18. März 2010 10:07:59
PS L:\BS\D\DriveSnapshot> $file.LastWriteTime
Montag, 24. Januar 2011 08:14:45

As you can see, when it salvages the files from ext3 to ntfs, DiskInternals Reader uses the linux/ext3 Change date/time as the Creation date in Win7, which is correct given that linux does not have a birth date for files. The Access time/date is different of course, but the relevant Modify date/time from linux is correctly represented as the LastWriteTime in NTFS and replicated exact to the second. This is also the time that is given in TC850 for both sides in the dir listing and in the sync window.

I therefore do not think that this is a time stamp problem. Also, the ignore 1 hour difference in TC did not make a difference (see above).

Is there anything indicative about the fact that all file pairs have a "?" mark as their status flag after comparison?