Lister bug with RTF files

[beernutz]

I don't know when this bug cropped up, but it happens in the b24 version of TC.

Basically just F3 on this file, and toggle word wrap on and off a few times, you will see the bug.

Here is a link to the 346 byte test rtf that shows the problem.

http://www.beernutz.org/rtftest.rtf

Thanks again for great software!

[tbeu]

TC7.57a adds new backslashes with every toggled word wrap until it hangs. TC8PB24x64 fails to display the file when toggling with key W from keyboard.

[umbra]

Confirmed. However I think there are two different bugs:
1. The provided file is invalid and all TC versions (7.57a, 8.0x32 and probably 8.0x64) will keep adding backslashes every time you enable/disable wrapping.
2. When you enable wrapping in TCx64, the text will lose its formatting (as if it was just a simple text file). I've made a new bug report for that: http://ghisler.ch/board/viewtopic.php?t=34145

2tbeu
TCx64 doesn't show nothing - it shows the same "something" that you can see if you try to open that file in WordPad.

[karlchen]

Hi, guys.

I am not sure that Total Commander's internal lister has got problems displaying genuine and valid RTF files.
The point might be that the sample file rtftest.rtf is not a valid RTF file at all.
E.G. Word 2010 refuses to open and display the file, because the file were damaged. So does Softmaker's Textmaker 2012.
So if Total Commander's internal lister should be doing something incorrectly, then it may not verify carefully enough that a file which pretends to be RTF really is RTF.

Kind regards,
Karl

[umbra]

Hi, karlchen.
We already know the file is not valid. But it would be better if TC showed an error or loaded it into Lister as a simple text file. Currently, user might be confused. And the eventual crash is not nice either.

[karlchen]

The problem is that Total Commander does not check properly whether a file is a valid RTF file. It allows itself to be persuaded too easily to interpret a file as an RTF file though it is not a valid RTF file.

And of course the final crash is not really desirable.

The check which T.C. performs might be really extremely trivial: Changing the initial "{\rtf1" to "{\rtf2" in the referenced sample file convinced T.C. this file is no RTF file at all, but pure text. No wrapping problem.

Vice versa: prefixing "{\rtf1\" to a pure text file holding no nasty elements like backslashes, convinced T.C. the file were RTF and was sufficient to reproduce the reported bug.

Copy the following content into your favourite editor, save it under a random name (extension .RTF not needed), view it in T.C. lister, press letter w repeatedly to switch the status of wrapping repeatedly and start wondering what the heck lister may be doing internally

Code: Select all

{\rtf1\
version 1.11.2 "Hot fixes II" (2010-11-02)
        - Revert "mingw: add missing purple-notify.c to build" (Anibal Avelar)
        - Sipe-sign: fix parsing of P-Asserted-Identity header (Jakub Adam)
        - Fixed memory leaks (Stefan Becker)
        - Fix #3090663: Re-authentication fails (Stefan Becker)
        - Fix #3090663: Re-authentication fails (2nd attempt) (Stefan Becker)
        - Fix #3090663: Re-authentication fails (3rd attempt) (Stefan Becker)
        - Fix #3090663: Re-authentication fails (4th attempt) (Stefan Becker)
        - Apply patch #3091490: Make 1.11.0 Compile on FreeBSD (jprather)
        - Fix #3092324: Core dump in "make check" (Stefan Becker)

The text really is irrelevant. The important part is the initial string "{\rtf1\". I just chose that text because it came inside a pure text file named "news", no formatting whatsoever, no RTF.

This can be reproduced using T.C. 7.56a, T.C. 7.57a and T.C. 8.0ß24 32-bit.

Note:
The reported misbehaviour can be reproduced only very partially when using a 64-bit T.C. version.

Karl

[Dalai]

Vice versa: prefixing "{\rtf1" to a pure text file holding no nasty elements like backslashes, convinced T.C. the file were RTF and was sufficient to reproduce the reported bug.

Maybe I'm doing something wrong but I wasn't able to reproduce the behaviour using the code you provided (neither 7.56a nor 7.57a nor 8.0ß24). Lister shows the same text no matter how often line wrap is toggled. On the other hand I'm seeing a huge CPU load and increasing memory usage using rtftest.rtf. Don't know if it crashes eventually as I didn't want to wait .

Regards
Dalai

[karlchen]

Hello, Dalai.

About my code and the reported results:
I verified that the posted behaviour occurs, too, when using a fresh.ini. (I had suspected htmlview to interfere, but apprently it does not) Therefore I cannot explain why you should get a different result.

Maybe the Windows version is relevant for the result details: Windows 7 Enterprise Edition SP1 32-bit

And yes, using the initial sample file which brought this thread into existence will not always make T.C. crash, but instead lister and T.C. will become unresponsive after pressing "w" several times. ... Hm, pressing "w" often enough will make T.C. crash eventually. (pressing "w" 20 or 30 times)

Kind regards,
Karl

[karlchen]

Hi, folks.

It is more complicated than the sample text prefixed with "{\rtf1\" suggests.
The text following on the lines below the string "{\rtf1\" does matter.

This time a copy of the file "size!.txt", to be found inside %COMMANDER_PATH%, was used. This is to avoid that copying the code from this webpage might add trialing space characters which in turn might influence the testing result. Might. Do not know.
The string "{\rtf1\" was prefixed above the original text of size!txt.

And ....

Nothing much really. It looks as if lister might think this is an RTF file. Yet, switching wrapping on and off till the keyboard breaks refuses to yield any negative side effect.

Hm.

Karl

[ghisler(Author)]

Sorry, it would be asked too much to completely verify an RTF file before passing it to the Windows RTF control. Therefore you will have to live with it, sorry.