"Garbage" data shown in Sync dirs

[Hacker]

Hi,
We have a report in the Slovak / Czech forum about "garbage" being shown in the initial step of the directory synchronization, e.g. there are dozens of "autoexec.bat" files shown in the root dir for a fraction of a second. This started with TC 10.50 b5, 64-bit only (32-bit is OK). Here are some recorded screen captures, you might need to watch them frame by frame to see the issue.

Compare_Disk_D_(25 900 files, 1 293 dirs)
https://u.pcloud.link/publink/show?code=XZbb9RVZy5oIEPhnnQywjlzacIAnOR5OUfnV
Compare_USB_K_(6 734 files, 592 dirs)
https://u.pcloud.link/publink/show?code=XZGb9RVZH0YrhOKYRtp3rCYcFv5lIkus3WTk

Roman

[white]

Hi,
We have a report in the Slovak / Czech forum about "garbage" being shown in the initial step of the directory synchronization, e.g. there are dozens of "autoexec.bat" files shown in the root dir for a fraction of a second. This started with TC 10.50 b5, 64-bit only (32-bit is OK). Here are some recorded screen captures, you might need to watch them frame by frame to see the issue.

Compare_Disk_D_(25 900 files, 1 293 dirs)
https://u.pcloud.link/publink/show?code=XZbb9RVZy5oIEPhnnQywjlzacIAnOR5OUfnV
Compare_USB_K_(6 734 files, 592 dirs)
https://u.pcloud.link/publink/show?code=XZGb9RVZH0YrhOKYRtp3rCYcFv5lIkus3WTk

Roman

Translation of the report by google:
https://www-ghisler-ch.translate.goog/board/viewtopic.php?t=76940&_x_tr_sl=cs&_x_tr_tl=en

Summary:
After clicking the Compare button in Synchronize Dirs the result list is temporarily filled with erroneous data.
The issue is reportedly only exits for the 64-bit version and only since TC10.50b5 and tested up to version TC10.50rc3.
Comparing is done with only the options "Subdirs" and "Empty directories" enabled.
The issue has only been detected when comparing many files/folders.

Movie 1 shows that when the reading of folders is finished and comparing is at 70% and 99% the results lists is filled with the same Autoexec.bat file many times.
Screenshot

Movie 2 shows that the results list is temporarily filled with folder names.
Screenshot (this screenshot will be removed after 1 month)

[ghisler(Author)]

Thanks, it looks like calling listbox.perform(wm_setredraw,0,0) doesn't work in Lazarus, only in Delphi, so the list is redrawn even while it shouldn't be. Calling SendMessage works.

[ghisler(Author)]

2Hacker
This should be fixed in RC4, could you please ask in the Slovak / Czech forum whether they can still reproduce it or not?

[Hacker]

Christian,
I did, but the user mentioned he'd be in the hospital for about two weeks, so I assume we won't get a confirmation soon.

Roman

[ghisler(Author)]

The problem only occurs when using a screen reader, because then the faster method to add strings is turned off. You can simulate it by using the Microsoft tool inspect32 to send LB_GETTEXT to the main TC file lists, which turns off the option.

This is done because when using the faster method (LB_SETCOUNT), then some screen readers fail to send LB_GETTEXT to get the lines from the listbox. Therefore when TC detects a screen reader, it uses the slower LB_INSERTSTRING to add each line separately, which can take a lot of time when there are many 100000 results.

[MaxX]

I remember such a problem on some betas or RC of 10.50, it was on Win 10 wish old iGPU and driver, on usb 2.0 hdd (external box for sata 3.5"). Also I had some another graphical glitches, so I didn't pay attention to that.
I plan to boot that hdd again and try to check it on 10.50 final.

[ghisler(Author)]

Any news? Did it occur again to anyone?

[Hacker]

Christian,
The user who reported the problem originally has not responded yet, probably still in the hospital, unfortunately.

Roman

[MaxX]

I did not see that again. I'll feedback if something goes wrong.

[ghisler(Author)]

2Hacker
Sorry to hear that! I hope that he will be OK soon.

2MaxX
Great, thanks! I will move this thread to "fixed bugs" for now, and may move it back if someone else has the problem, or the original poster reports back.