tc.*-fields and FS plugins

[Lefteous]

Although I'm a plugin developer I have never really dived too deep into FS plugin development. So please excuse my question from a FS plugin developer point of view. So I'll describe it from a user perspective.

I started a search in a FS plugin (Secure FTP) and displayed the search in a custom column view (Name, Ext. tc.Path, tc.Size). All columns except tc.Path were displayed as expected.

So who is responsible for displaying those internal fields? Some seem to work and others don't - quite confusing.

[Balderstrom]

TC.X fields are fully internal and part of the TC Binary.

TC.Path likely requires a local system file, and would require an equivalent FS field (for SFTP). Or for an exception to be coded into the TC binary.

I don't think SFTP "understands" Paths. As shown in the Address Bar when you are connected.
What is displayed is more like a virtual path:
"0:\www\css"

Kinda like how TC doesn't completely understand Libraries::
If you have the same file in multiple Library locations, TC shows all files sorted by name, with duplicate files displaying, and using custom columns with [Tc.Path] is completely blank.

Or like how TC only allows you to go to the "Desktop" from the Address Bar drop-down
Which then shows \\Desktop\*.* as a fake path.
As you can't actually type that into the Address-Bar to get to the desktop.

And when you are in the fake desktop path, [TC.Path] is blank again.

Or how if you go to the desktop, open a folder on the desktop - TC changes to the absolute path, and going up a level takes you up one level from the absolute path - instead of back to the desktop.

[Lefteous]

TC.X fields are fully internal and part of the TC Binary.

Yes they are internal fields. But that doesn't mean these fields don't ask FS plugins for values. For the date and size fields TC definitely asks the plugin for values - but obviously not for the paths. So it seems some fields are mapped to the internal tc fields. So far I can't see pattern which fields are mapped and which not.

[Balderstrom]

Right, but to access FS plugins we have to go to "\\Network\*.*"
And then click on the relevant FS plugin.

These are all virtual (non-system) folders -- There is no "path" for any of them.

I just installed Flint's Uninstaller64. It adds a few fields specific to itself, but only 4 of the "tc->" fields show up (out of 28) ::
size, writedate, writetime, attributestr.

So the FS plugin can query some of the fields, but paths don't exist for virtual folders. When you are using TC's SFTP you don't get a normal context menu (if I recall), and you can't perform normal file operations.
Similar to how you get a non-standard context menu with Flint's Uninstaller64.

As opposed to something like FTP Drive (which last I checked doesn't work with Win7 x64), which did provide native context menus and normal file operations.

[Lefteous]

2Balderstrom
Yes there could be multiple ways to display a path of a FS plugin. I don't think it's right to say there is none. First of all in my example I searched in a FS path and the result were presented as full paths in the search result window. I think it would be straightforward to use these paths as the directory path part in tc.path (tc.path semanitically doesn't contain the filename).

On the other hand there is also something that I would call 'native path' which is standardized path format for remote connections e.g. FTP or webdav paths. I think this is something that just the plugin knows but it's of course also a valuable information. For FTP it's displayed in the volume bar - for Secure FTP it's just unnamed.

BTW: A long time ago I suggested to introduce a mechanism in TCs content field system that would map plugin fields into predefined categories. This would mean there is a field called "Comment". The plugin author knows this and signals that a certain field fits into this field. The user may now select from all fields which to use but semantically matching fields would be presented as matching (which may vary on file type or other conditions). Of course the user could also create these 'meta fields' but in this case he doesn't get a preselection
I know there is a plugin that works similar but it's one of the things that should definitely be part of the core package.

[ghisler(Author)]

Indeed the internal "tc" plugin gets some of its fields from what the plugin provides, including name, extension, size, and timestamp. Some other fields like the above mentioned path are usually useless, because they are not part of the local file system.

[Lefteous]

I think it's quite handy to see the directory paths - remote or local doesn't really matter - in order to handle search results effectively. In my scenario almost all found files had the same name...