Is TC 7.5 public beta out?

[m^2]

But how do you want to store it inside w/out breaking file structure?

[Lefteous]

There are two parts. The file format and the program reading the file. If the file format is designed for meta data it's not a big deal. If not the program must be aware of files containing metadata and handle the contained structure not as file content but as metadata. A standard for metadata strutures helps a lot.
I know this sounds stange to you raw edit guys but that's the way it's gonna have to be.

XMP is an interesting approach: http://www.adobe.com/products/xmp/

[m^2]

Support your idea. Now let's go to all the people who maintain any program that reads any files and convince them to implement such tagging awareness.
When we're done, it will be a great addition to TC.

[balver]

I see there are many ideas how to implement support for Unicode comments. Therefore I came up with another (crazy) idea. A new plugin interface. TC internaly already tracks all copy/move/rename actions, so it could call a DLL function in such situations. If we had this we could even have the ability to use XML, DB and ADS at the same time

[Innuendo]

Mr.Ghisler has a file ID availabe for using with TC (0xC2, as received from inventors of descript.ion), which he already applys to descript.ion comments containing line breaks. Thus, Hacker's suggestion is probably valid.

In my mind the simplest and most logical way to solve this problem is for the inventors of descript.ion to assign a new "file ID" for dealing with Unicode files.

In other words, when a standard does not cover something that someone wishes to implement then the simplest way to go about solving the problem is to extend the standard not invent a new one.

The only reason descript.ion files do not support Unicode is because the file format was invented in the days of MS-DOS. I cannot speak for everyone, but I would think that logically the backwards compatibility with MS-DOS can finally be let go in this modern day and age of 2009.

Stealth edit after posting: The obvious benefit from this solution would be that every other program out there that makes use of descript.ion files would be able to reap the benefits of being able to utilize Unicode file descriptions and would not be a Total Commander-only solution locking out all other programs.

[ghisler(Author)]

In my mind the simplest and most logical way to solve this problem is for the inventors of descript.ion to assign a new "file ID" for dealing with Unicode files.

Unfortunately this doesn't work. The extension ID applies only to the description itself, the name field isn't affected. This is necessary so other programs can ignore extension IDs which they do not know.

The inventors of descript.ion would have to come up with a new standard which includes Unicode.

[m^2]

Either they or you.

[Innuendo]

The inventors of descript.ion would have to come up with a new standard which includes Unicode.

Those guys have been around a very long time and they are brilliant programmers. You, too, are a brilliant programmer, Christian. I'm sure if you all put your heads together you could come up with either an extension to the old standard or a new standard if need be.

A very simple extension to the standard, if backwards compatibility were absolutely required with older programs would be to store non-Unicode file descriiptions right where they are at in descript.ion and all Unicode file descriptions in a separate file named, for example, descript.uni.

All old programs implementing descript.ion support would ignore descript.uni while all newer Unicode-aware programs could read both descript.ion and descript.uni.

This would probably be considered to be "an ugly hack" by you elegant programmer-types, but it'd get the job done, I think. I just don't know how much overhead would be introduced by reading and processing a second file.

I'm fortunate in that I never work with Unicode files so these new limitations really don't affect me, but I'm lost without my file descriptions so I'm reasonably sure that there's probably a good segment of the user base out there who feel the same way about file descriptions as I do but also work with Unicode files on a daily basis.

Perhaps you could take my 'ugly' idea to the 4DOS/4NT guys (They're the ones who invented the descript.ion format if I remember right) and all of you could re-work my hack into something elegant and usable.

The future of computing is Unicode and the future is here now. Of course, you already believe this or you wouldn't have done such extensive updating to TC to make it Unicode-aware. Descript.ion is going to have to be updated as a file format standard if it is to survive and thrive in a Unicode world. Otherwise, left as it is, it's going to eventually become a quaint oddity of the MS-DOS age like QEMM.

[fenix_productions]

Just thinking...

2ghisler(Author)
Does descript.ion require full file names or can it use 8.3 ones?

If the second: maybe Unicode names could be stored that way and you could put proper names in description part with your ID usage (just to be sure that 8.3 name reflects Unicode one). This could be workaround but you know better this standard

[m^2]

Not a great idea.
Every time you add some files to a directory with description, TC should correct short names.

ADDED: Actually it seems a very bad idea. Making it reasonably fast and secure at the same time seems more complicated than implementing whole new descriptions format.

[fenix_productions]

2m^2
Thanks for info. It was just a thought

[petermad]

Does descript.ion require full file names or can it use 8.3 ones?

It can use 8.3 names, but the description is only shown if UseLongNames=0, once you switch to UseLongNames=1 the description is no longer shown.

And the 8.3 name for long names might change when the file is copied/moved to another folder.