Problem with 'Synchronize Dirs' + dirs created by browsers

[jb]

The 'Synchronize Dirs...' command of TC V5.51 does not work correctly when applied to directories created by web browsers.

It took me quite a long time to get a reproducible situation. Here it is:

1. Go for instance to http://www.ghisler.com/ with a web browser such as Mozilla V1.3 or IE V6.0 SP1.
2. Save the web page to C:\SyncDirTest\SubDir with the 'Save As..' command. Use 'Save as type:' "Web Page, complete".
   NOTE: SubDir is important for the test!
3. Start or activate TC V5.51.
4. Copy C:\SyncDirTest to C:\SyncDirTest_.
5. Rename C:\SyncDirTest_\SubDir to C:\SyncDirTest_\SubDir_.
6. Open C:\SyncDirTest_ in the right window of TC and C:\SyncDirTest in the left one.
7. Invoke 'Synchronize Dirs...', set 'Asymmetric' mode, set only the show button 'Files to copy from right to left' (blue arrow button) and press [Compare]. Now you should see all files of C:\SyncDirTest_\SubDir_ selected for deletion.
8. Press [Synchronize…].
9. Make sure that option 'Delete … file(s)' is checked. The other settings do not matter. And finally press [OK].
10. Confirm "Do you really want to delete the … selected files/directories?" with [Yes].

And now the problem occurs with the following message box:
File "dkgray.gif" not found!
[Skip] [Retry] [Abort]

After pressing [Retry] the following message box is shown:
Access denied on file
"dkgray.gif"!
[Skip] [Retry]
[Skip all] [Abort]

After pressing [Retry] again, the following message box is shown:
Error: "dkgray.gif" cannot be deleted!
Please remove the write protection!
[Skip] [Retry]
[Skip all] [Abort]

The message box is repeating if you press [Retry].

If you press [Skip], then the strange game goes on with the next file.
In the end all files are deleted regardless whether you press [Abort] on the first occasion or whether you press [Skip] many times.

I noticed that the folders created by web browsers have special properties. In the Properties Dialog (Alt+Enter) there is a special Web Sharing tab.

What are the reasons behind the described behavior

[ben hub]

just tested exactly what you explained.

no problem for me, the files were deleted without error.

tested under W98. I'll try tomorrow under xp and w2k...

[jb]

I made my tests with Windows 2000 SP3.

[ben hub]

tested under xp family 2002 sp1 (french) :
the problem you describe occurs in the same way.

[ghisler(Author)]

The problem is the following: When Windows deletes a html file called sample.html to the recycle bin, it also deletes a directory called sample_files (if it exists), so when TC tries to delete the dir itself later, it cannot be found! You can turn off this odd behaviour with TweakUI.

[jb]

Thank you both ben hub and Christian very much!
This odd behavior really bothered me. Above all because I did't know whether my system or my disk is corrupt in some way.

[jb]

To Christian:
Perhaps TC could check the corresponding setting in the registry and prevent the puzzling message boxes or extend them with your explanation above if it's not too much work. Otherwise it is likely that someone else will ask my question again and it will take time to read and answer it again, apart from the fact that of course also the puzzeled user will waste his/her time.

[jb]

You can turn off this odd behaviour with TweakUI.

More precisely: Uncheck the option "Manipulate connected files as a unit" located on the Explorer tab of Tweak UI V1.33.

The corresponding help text reads as follows:
If the "Manipulate connected files as a unit" box is checked, then any operations performed on Document.htm (or Document.html) will also be performed on "Document_files" and vice versa. For example, if you delete Document.htm, then the Document_files folder will also be deleted.
This is a per-user setting, not available on all platforms.

[ghisler(Author)]

Perhaps TC could check the corresponding setting in the registry and prevent the puzzling message boxes or extend them with your explanation above if it's not too much work.

Yes, it's already on my to do list. I'm already doing this with normal deletes, just not with synchronizing.