SFV extensions

[milan_va]

I need a program to check another type of file signature, called a TTH root. I understand it's pretty rare, so I thought about new plugin type and a plugin. Another plugin of this type could do the *.CSV you are talking about.

The plugin interface could be quite simple, just
a) get a root path and relative filename and return a line of text and
b) get a root path and a line of text and return the filename (or check it at once)
c) return file extension (?)
Or I believe so.

Does anyone else think this plugin (type) would be used widely ?

Milan

--
For explanation of tree hashes go to http://www.open-content.net/specs/draft-jchapweske-thex-02.html, chapter 1 and 2.
Tiger hash is standardized, for implementation see http://www.cityinthesky.co.uk/delphi.html .

[milan_va]

Hello again.

I was thinking about it and noticed that "sfv" plugin could be joined with the "search" plugin suggested last september or so. The merged plugin would be named like "metadata plugin" and in search, you could specify a value this plugin gives. To sum up:
1) A plugin returns names and types (String, Int64) of data it returns.
2) In search, you could specify a plugin, it's function and value pattern (string) or range (integer).
3) When making a .sfv file, you could choose a predefined line format or define your own.

Example for 2: [std.size]>10000, [mp3.artist]="*Jean*"
Example for 3: [std.name] [std.crc32] (for .sfv)
or [std.name],[std.size],[std.crc32],[std.path] (for .csv ver 2)
or [tth.root] [std.name] (for .tth)

It would be fun to search for files by their md5sum, don't you think?

Milan

[Hammillian7]

I'm not sure wether this is the place to suggest it, but what I'm looking for is something like this:
+ When I command a .sfv file generation, I get a file containing the combined info of the current .lst plus the CRC. Suppose its named .lfv (whatever name the implementor chooses).
+ I can get inside the .lfv as inside a packer (like with the current .lst).
+ (new and seeked) I can command "Syncronize Directories) and "compare by contents" and this one calculates the CRCs of the other pane and compares them with the .lst ones, giving the result as if it had compared their true contents.
+ The previous point extended to comparison between two .lfv packs entered into on the 2 TC panes.
+ When I'm inside that pack, the contents of each file is represented by its CRC and this is what is compared when choosing, for example, "File, Compare by contents".
(or maybe in a lightly different implementation)

That's to say, I would like the current .lst packs to include the CRC of each file, representing its contents, and that the main tools for comparison by contents (the one under the "File" menu and the "Sycronize Directories") use the CRC for that comparisons, both between entries inside a .lst and between these ones and normal plain files.

Or should I start a new poll for this request?