Moderators: white, Hacker, petermad, Stefan2
I can confirm that Autoit - exe files (compiled autoit scripts) frequently trigger false alarms with several Virus scanners.Stiltzkin wrote:can anyone confirm that the 'TCEditCommentExtended.exe' and the 'ArcInfo.exe' within the TCEditCommentExtended_0.3.0.zip contains the signature of 'Worm/Sohanat.H' ?
thats what 'avira antivir' is telling me after the latest virus definition update...
hope its a false alarm...
I haven't notice anything new concerning edit comment in the brilliant new TC7 (the most I used it the most I discover nice featuresLefteous wrote:2van Dusen
I have to interfere a bit here. Maybe you read here which improvements can be expected in TC 7.
Don't get me wrong your add-on seems really good but I guess there will be an internal solution for similar tasks in TC quite soon. I just can't watch and keep silent how someone writes such a complex tool parallel to an internal TC solution.
) did I miss something? Anyway I like TCEditCommentExtended. Press Files/Change attributes. Press more attributes. The first field presented is tc.comment. Now you can enter a new comment for all files directly. Another way is to use the >> button which opens the known comment edit dialog box. The + button adds plug-in fields as source for the new value. This can be used to overwrite the current comments or to combine the old comments with a fixed text and so on.I haven't notice anything new concerning edit comment in the brilliant new TC7
Isn't that what you are doing now (in Total Commander 7.50 public beta 1/2).ghisler(Author) wrote:descript.ion isn't a format with which you can do what you want! It was introduced by the makers of the tool 4dos and 4nt. These tools limit the length of the descript.ion line to 512 characters, and do not support any line breaks. TC would break these tools if it ignored their restrictions. Unfortunately as you have noticed there are some programmers which simply ignore other programs and do what they please with a file format.
It's not OK to interpret a \n as a line break. That would mean storing program specific data into the description. Program specific data should be behind a <Ctrl-D><ID> mark. \n are normal characters. To interpret them differently means changing the format. What would happen if more programs would add special characters (for instance $,#,etc.) with special meaning? If this is allowed there's no need to use the <Ctrl-D><ID> method. Every program could add his marks to the decription. For example:icfu wrote:http://jpsoft.com/ascii/descfile.txtThe characters
after the description allow extension of the description format
for use by other programs. They are as follows:
* is an ASCII Ctrl-D (04), and marks the end of the description
text and the beginning of information for a program other than
4NT or Take Command. This symbol can appear multiple times on each
line; each occurrence marks the beginning of information for another
program.
[...]
The line length limit is 4096 bytes; exceeding this limit will cause
unpredictable results.
So, it is completely ok to use descript.ion files longer than 511 bytes up to 4096 bytes and it is also ok to interpret a \n as a line break.
Code: Select all
[programX:author]Description line 1[TC:newline]Description line 2.[programY:shooting date]
It is.It's not OK to interpret a \n as a line break.
It would not.That would mean storing program specific data into the description.
There is a difference between program specific data and a user's choice to have \n interpreted as a line break in the common descript.ion area.Program specific data should be behind a <Ctrl-D><ID> mark.
The format isn't changed by the way how printable characters are interpreted by programs.\n are normal characters. To interpret them differently means changing the format.
Besides that Mother Earth would collapse, it would mean that these descript.ion files could be edited normally in all apps with descript.ion support.What would happen if more programs would add special characters (for instance $,#,etc.) with special meaning?
You haven't understood the ID concept, just like ghisler, who has totally fucked up this descript.ion implementation.If this is allowed there's no need to use the <Ctrl-D><ID> method.
He doesn't set the ID when comments reach the limit of 511 chars, but instead he sets the ID only when line breaks are used, but instead of IN FRONT of the first occurence he puts the ID at THE END of descript.ion. This will of course lead to data loss in descript.ion files when edited in other applications.
Funny, I thought that was the definition of format. So basically you are saying that when the format is that the first 20 characters are for storing first name and the following 20 characters are for last name, it's OK to interpret the first 20 character as last name and the following 20 characters as first name. I wonder what your definition of format is.icfu wrote: The format isn't changed by the way how printable characters are interpreted by programs.
Exactly, that's possibly the reason why people may want to misuse the description when they want to to extend functionality.icfu wrote:Besides that Mother Earth would collapse, it would mean that these descript.ion files could be edited normally in all apps with descript.ion support.What would happen if more programs would add special characters (for instance $,#,etc.) with special meaning?
Enlighten me.icfu wrote:You haven't understood the ID concept..If this is allowed there's no need to use the <Ctrl-D><ID> method.
