Two bugs still in 4.9.28 and req.
 

Is there a "bug report" forum? There really needs to be one.

Two "bugs" I've long noticed in recent versions (including the current 4.9.28 Pro):

If you Describe a file, anything entered on the "Action" line does not appear in the mouseover popup.

And if you right-click the column headers on the search page to define your columns, eventhough there are separate lists for "Audio" and "Video", the column header you select is shown no matter what (ie: check "Bitrate" under Audio but not Video and it's still inserted even during video searches) why have separate "checks" for "Bitrate" or "Artist" under both Audio and Video if you're going to add that column no matter what?

And my (long standing) request is for file descriptions to be saved in a separate database that can be reused (and edited) even if LimeWire crashes and must be reinstalled.
(and the ability to search by description and file size).

Well, the "Action" field is special and should not be displayed. Whatever you enter here will not be used.

It is used internally, for historical reasons and compatibility with internal XML management, but not for storing meta-data. So it's normal that it won't appear in mousehovers.

Regarding the export of metadata, I do agree that LimeWire should have an option to import/export meta data into separate files (possibly with individual files sharing the same name and location as the annotated file, but with an extra extension.

On Windows NTFS, a new filename with an extra extension would not even be necessary with ADS (alternate data stream), so that the meta-data are always kept along with the file even if it is moved to another location or to another NTFS filesystem). But unfortunately, Java currently has no support to reads/write of ADS files.

On MacOS(X), there are "equivalent" resource forks, but they are considered part of the file. When resource forks are moved to non MacOS filesystems, they are stored in a file placed in a specially named subdirectory. (But if you look at these filesystems on other OSes, you may forget to move the resource forks along with the normal data forks of the file, so this is not a good option.

For me the simplest would be for LimeWire to recognize and import/export meta data within small plain-text properties files with the extra ".meta" filename extension.

A good solution is when meta-data can be incorporated within the datafile: this is what happens with "tagged" .MP3 files. Unfortunately, this modies the data file content, so this only works well when the meta-data is mostly unmutable.

The best solution will come when filesystems will become relational instead of stupidly hierarchical only (a relational filesystem was initially scheduled for Windows Longhorn, but I don't know if this has been delayed again; there's still no equivalent in Linux and MacOSX, and relational filesystems only exist as extensions of large classical RDBMS like Oracle).

The Windows XP filesystem looks like a small introduction by summary support of the "object" filesystem which offers several limited but navigatable views of the same set of files. But this is only an Explorer feature, and not part of the system kernel which still needs hierarchical names, and offers no real service to allow finding supplementary relations between "file" objects and "metadata" objects (like most other existing filesystems, it only offers the "contains" relation between a "container", in a special file named directory, and "file" objects, and not even the reverse relation also not supported on Unix and Mac filesystems).