SyncDirs, comparing RAR by contents - overwrite requests

[Flint]

1. Create a RAR archive with several files with identical names in subdirs. If you are lazy you can just take my VirtualDisk plugin.
2. Open the archive in one TC panel, and its unpacked contents in another. Open the SyncDirs tool.
3. Select "subdirs" and "by content" checkboxes, press Compare.
4. While comparing, TC requests to overwrite the file temporarily unpacked during comparison (%TEMP%\vd_filedisk.sys in the VirtualDisk package, for example). If there are many files with identical names, it becomes very annoying…

This is quite strange, however, because when I open TEMP in another TC instance while seeing this overwrite request, the _tc subdirectory is empty, so I don't understand why TC asks to replace anything at all. Probably, some timing problems…

[ghisler(Author)]

Not confirmed, tried on 32-bit XP SP3. I compared the archive with itself (same archive on both sides).

Maybe a virus scanner problem?

[Flint]

ghisler(Author)
Not archive with archive, but archive with its unpacked contents.

But it seems that antivirus is indeed the source of the trouble. When I turned it off, I could not reproduce the problem…

[ghisler(Author)]

It could be because TC is now deleting the subdir after unpacking and deleting the file. I will check that.

[ghisler(Author)]

I have checked it now, and it's not the problem I suspected: The sync tool unpacks all the files to the _tc folder itself, not to any subfolders.

Maybe you have multiple files with the same name in that archive (in different subdirs)? Then the unpacking may fail because the scanner is still scanning the previous file, so Windows couldn't delete it...

[Flint]

Maybe you have multiple files with the same name in that archive (in different subdirs)?

Yes, I wrote that in the first post.

Then the unpacking may fail because the scanner is still scanning the previous file, so Windows couldn't delete it...

How can I check this? I don't think that the antivirus blocks the file in such a tricky way that DeleteFile returns success but the file remains where it was. So, TC should receive failure code. How does it handle it? Just ignores silently? Maybe, in such situation it would be better if TC created a subdirectory of gave the temporary file another name using e.g. the built-in auto-rename technique with adding (2), (3), etc.

[ghisler(Author)]

How can I check this?

Try with "process monitor" from sysinternals.

[Flint]

Here is the part of log:
http://flint-inc.ru/Temp/tcbeta75/syncdirs_procmon.log
It contains the removal of the file vd_filedisk.sys and checking for its existence before creating the same-named file for unpacking.
Unfortunately, I don't know what SetDispositionInformationFile means, as well as why it is used instead of DeleteFile or something like that…

[ghisler(Author)]

According to Google, SetDispositionInformationFile with "Delete: True" is the internal function to delete a file. As you can see, it returns SUCCESS, so TC assumes that the file was deleted.

I wonder what I should do in this case:
1. Wait and try again later? Unfortunately some scanners can take several seconds to scan a file
2. Rename the file before deleting? Unfortunately this may cause yet another scan with some scanners

[Flint]

According to Google, SetDispositionInformationFile with "Delete: True" is the internal function to delete a file.

I see…

I wonder what I should do in this case:

Well, the most logical solution would be not to drop all files directly into _tc but reproduce the archive directory structure. This would allow to avoid name collisions.
Another possible solution I suggested above: if TC tries to create a file which exists already, do not ask user for overwriting but silently rename it into something like file(2).ext.

[ghisler(Author)]

OK, I have now added an auto-rename to the upcoming RC2 for the sync function only - let's hope that it helps...

[ghisler(Author)]

Flint has confirmed the fix in RC2, thanks!