Synchronize Dirs: aborts when 1 file can't be overwritten

[StatusQuo]

If synchronizing files in a RAR-Archive with the contents of a folder, the function aborts after the first file that couldn't be overwritten. All the undone rest of the copy-action won't be executed, instead the comparison of both sides starts again (undoing all manual changes of copy directions).

Example to see the problem:
- on the right panel go to an empty directory and put 3 files there, that are normally opened by a MS Off*ce-Application (W*rd; Exc*l would also do), i.e. 1.doc, 2.doc, 3.doc
- pack these 3 files into a RAR archive
- open this RAR archive in the left panel
- on the right panel (the unpacked files) mark all 3 files and change their "date last changed" information to a value 1 day earlier than before, so the files seem to be older (i.e. with menu function Files / Change Attributes)
- on the right panel (the unpacked files) open the first file (1.doc) with WinW*rd, so it gets unwriteable for other applications
- call the menu function "Commands / Synchronize Dirs" (on the left panel the contents of the RAR files, on the right panel the unpacked test-files), start synchronizing and let TC overwrite all files
=> Nothings get copied/synchronized, instead the whole process is aborted after the failed write-access to the first file.

Edit:
.rtf changed to .doc, because the problem seems to appear with *.doc/*.xls, but not with *.rtf.

[ghisler(Author)]

This is considered a fatal error, so the synchronizing is aborted.

[StatusQuo]

Unfortunately the user gets no information, why the synchronization function exits without completing its job.

The optimal way IMO would be a possibility to continue with the next file (especially because this way the user would not lose former made decisions about what file to copy in what direction).
If that's impossible, a popup-info about why it aborts ("no write access to..." or simply "fatal error processing file...") together with the filename would at least help the user to manually exclude the unwriteable file from the sync list.

Perhaps this info can be retrieved in the unpacking process?

[StatusQuo]

Edit:
Not
Fixed in 7.0rc1.

=> see next posting.

[ghisler(Author)]

Interesting, I don't remember changing this function. Are you sure that the behaviour has changed?

[StatusQuo]

Interesting, I don't remember changing this function. Are you sure that the behaviour has changed?

Not really, sorry.
This seems to depend on the way of locking the file by another application (Exc*l always fails / WinW*rd fails with *.doc, OK with *.rtf).

Summary:
Clicking on "Overwrite" will not overwrite anything, but abort the complete process (ignoring all further files in the list), if some files, which are to be overwritten with the contents of an archive, are opened & locked by some application.

Tested:
*.rtf, WinW*rd 2000 + 2002, W2k Pro SP4 + XP Pro SP0:
All OK, files with "access denied" can be skipped via dialog.

*.doc, WinW*rd 2000 + 2002, W2k Pro SP4 + XP Pro SP0:
=> Abort without user info on the first "access denied" (as described in "Summary" above and the first posting).

*.xls, Exc*l 2000, W2k Pro SP4 + XP Pro SP0:
=> Abort without user info on the first "access denied" (as described in "Summary" above and the first posting).

Behaviour with RAR and ZIP archives seems to be the same.
(TC's internal unpackers always must be used, because TC's option to use external ZIP/RAR unpackers is ignored in "synchronize dirs").

This problem doesn't come up when
- "synchronize dirs" is used on 2 normal directories (no archive on any side)
- F5 copy function is used instead of "synchronize dirs"

File structure for testing:

• - left panel: packed into RAR or ZIP archive, right panel: unpacked
  - *_opened.* are opened & locked by WinW*rd / Exc*l
  
  doc_0.doc
  doc_1_opened.doc
  doc_2.doc
  rtf_0.rtf
  rtf_1_opened.rtf
  rtf_2.rtf
  xls_0.xls
  xls_1_opened.xls
  xls_2.xls