[11.02rc2] Space on a directory fails to calculate size

[Stoebi]

No! Please. I don't like having to switch to other programs all the time. That shouldn't be a solution. More like a short-term solution.

[Horst.Epp]

No! Please. I don't like having to switch to other programs all the time. That shouldn't be a solution. More like a short-term solution.

There is no switching using Everything,
it's just fully automatic and superior compared to all other ways.
No problem if you don't use it, it's just wasting time.
You will have to wait for RC3 to get the fix.

[Boscon17]

I don't like using Everything...I prefer it to work like the previous versions of TC

[lneam]

Hi,

into this new version, when i press the space bar into a folder, there is no info about file size. It appears the symbol ? and no change. I return to v11.1 and it works again

thanks

[Horst.Epp]

A little bit late.
Please make a forum search before creating a new entry.

[white]

Moderator message from: white » 2023-10-15, 09:43 UTC

Duplicate bug report merged.

[HalbschuhTouri]

A little bit late.

That can be said about the much expected RC3-hotfix, too. With such a major glitch introduced in RC2 - and knowing about TC's otherwise ironclad reliability - I would have expected a hotfix for this issue sooner than after a full week (as it looks now), TBH.

[white]

Tested OK using TC 11.02rc3 32-bit and 64-bit.

[unter_officer]

Fixed in TC 11.02rc3.
Thank you!

[petermad]

12.10.23 Fixed: Getting the folder size with SPACEBAR stopped working (32/64)

Confirmed fixed in TC 11.02rc3

Moderator message from: petermad » 2023-10-18, 16:05 UTC

Moved to "TC fixed bugs" from "TC11.x bug reports (English)"

[AntonyD]

2petermad
People from RU forum complain that this fix was not tested and confirmed on win98.

[Horst.Epp]

2petermad
People from RU forum complain that this fix was not tested and confirmed on win98.

[AntonyD]

2Horst.Epp

Total Commander, Version 11.01, is a Shareware file manager for Windows® 95/98/ME/NT/2000/XP/Vista/7/8/8.1/10/11, and Windows® 3.1.

from https://www.ghisler.com

As you see Ghisler still want to prolong the support of these OS. So nothing strange will be in the case IF someone will try to test all bugs AND on these OS. Personally, I indeed would of course vote for support ONLY starting with windows 7
and for translating the entire code base into ONE language/platform - for example https://www.embarcadero.com/en/products/delphi
The development of this platform is amazing. Version 12 will be released soon. And there would definitely not be a problem with the fact that a bug from the 32-bit version is not present in the 64-bit version or vice versa. Or what’s even worse - in one version you can’t just go and do what is done in an elementary way in another. Our Total is probably already a third of the code consisting of some modifications to simply repeat what was done “in three lines of code” in another version... This is horror. And for some reason Ghisler is completely calm about it.

[ghisler(Author)]

I have checked this on Windows 9x and was able to reproduce and fix it. TC was checking for junctions/reparse points, which don't exist on Windows 9x.

[Hacker]

AntonyD,

The development of this platform is amazing. Version 12 will be released soon. And there would definitely not be a problem with the fact that a bug from the 32-bit version is not present in the 64-bit version or vice versa. Or what’s even worse - in one version you can’t just go and do what is done in an elementary way in another. Our Total is probably already a third of the code consisting of some modifications to simply repeat what was done “in three lines of code” in another version... This is horror. And for some reason Ghisler is completely calm about it.

This has been proposed and discussed many times in the past.
What you suggest would require taking a working Delphi 2.0 32-bit codebase, a working Lazarus 64-bit codebase, determine which one best to port (probably the Delphi 2.0 one), adapt it, squash all the bugs, work around all the problems resulting from porting from one compiler to a different one, accept the new compiler's limitations, where possible implement new workarounds, make sure everything works just as in the old version (including perhaps some specifically implemented timers, delays, workarounds which might not work with the new compiler anymore, etc.), check each form, window, dialog, etc. for pixel-perfect match of the previous version, check compatibility of all plugins and external libraries, etc., etc., etc., to gain, what, an easier way to debug?

I mean, let's look at the pros and cons. Pros:
- easier debugging, less bitness-dependent bugs (because the compiler is the same)

Cons:
- losing at least a year of improvements due to focusing on porting and fixing bugs instead of adding new functions
- new binaries might be slower
- unknown limitations of new compiler

Would it be worth it? Is there perhaps some easier / more robust way to port? Does anyone have any experience in porting Delphi 2.0 32-bit code and Lazarus 64-bit code to a current Delphi version, who'd be able to offer some insights? It's not as easy as "just switch compilers".

Roman