Save tag data and metadata in a separate file
For instance, have a text file Hello.tgd with a folder Hello, or Hello.jpg.tgd for Hello.jpg, which can store both the tags for a file, and let us add notes about a file. This would also let us keep hyperlinks to the file constant even when the tags change. (If a note was made here about every hyperlink TO this file, it could also auto-update links to the file when we move it)
Implelmented in the PRO version
-
Alex Koukarine commented
That is a BAD idea creating a clutter! The better one would be to have a single file for the folder like fileid.diz I recall from my FidoNet era, which contains the list of files in that folder with the full file name followed by an arbitrary note text. One line per file + header for the folder description at the top. It's proven to be extremely versatile by us, file hoarders for many years in the past (consider zipping the folder content - you always have the description file with them).
There must be an option to attach that text back to file names (truncating the note text to the OS defined max chars, so all the tags must go first to stay intact. And the reverse option as well.
Also to reduce the manual labor when the app is not available, I would ditch the NAME[TAGS].EXT notation in favor of NAME!TAGS.EXT notation - less typing ans shorter on the screen.
In fact for happy linking within MD link tags I would use just the file name portion only in the markdown, so then the parser would decide which file to open based on the name portion not the name with tags. Exactly as it's done when the file name is displayed (we don't see the tags tail).
-
Anonymous commented
Any plan to implement this feature in Android version?
-
Morgain commented
I need to use up to 10 tags on some items. Maybe more.
Now I'm only going to use it on one very large folder for a project - my PhD passionate dedication - but even so it'll be tricky to stay within 155 chars. -
nick commented
Messing with filename is breaking.... everything in unix based system, where everything is a file (with a name) . at this stage tagspace is just a mockup.
-
nick commented
we don't need 1 method, we need an API to plug different backends. But filename is probably the worse choice possible...
-
Floyd commented
The JSON (or whatever similar method) approach would enable much more versatility, and add database features to TagSpaces. Users could embed comments and pictures if they want to, and view them on the right panel, like media managers do.
-
Stefan Infp commented
This feature could function similar as File Metadata enables the tagging of all file types and backups/restores the properties of the selected files.
-
FreeFog commented
As said on other comments I would suggest saving the info on one file, and I add to that the idea of them having a fixed length, if exceeded the tag info would be split into a continuation file, and lastly the file should not store the info in a table or list fashion but more like something that could take the advantage of having everything in one place like:
red ; blue ; outdoors {
file1.txt ; file2.txt ; file3.txt
}file1.txt unique-tag · unique-tag3 ; file2.txt unique-tag2
Furthermore tagging directories could be useful, this was also said before, about them granting their tags to the files contained. By rule their tag info should be on their parent directory tag file unless it is the root, since directories are in essence files.
-
Annoynymous commented
Even after a day WinXP to Win 10, no flexible tag system exist.
Stefan Kuhn commented
"I believe creating separate files for tags and metadata in a hidden folder (similar to what SVN / CVS does) might be the best compromise"
This nice workaround, agree, it a best solution. Using a relative path -
Annoynymous commented
After with a lot of research, I think 1 file = 1 tag file is better.
Example
C:\setup.exe -> file
C:\setup.exe.tag -> separate tag fileBecause
- If you use extended attributes u cant use it on other platfrom. Its not crossplatform
You cant see your tag on Mac, Android, etc
- It easier to manage, to know, to modified, to support 3rd party app, a tagged file
Note : Make it the separate file readable, so u can still search using grep search (search inside file)
- No Filesystem dependency, no path dependency, no folder dependency, just filename dependency.
Just treat them like subtitle .srt fileProblem
- It can be alot of file generated.
Solution, u can hide this, or make tagspace hide it.Conclution
To make the tag crossplatform, future-proff, cloud storage friendly, for now there is only one way.
Readable separate tag file, not included in fileReference
http://www.xyplorer.com/xyfc/viewtopic.php?f=3&t=13677That solution maybe can accomplished by XYplorer with some script, but I need standard format, maybe tagspace can do it.
-
Vadim Scherbakov commented
I think that better case is to use single file per folder (may be JSON format) that store all tags of all files. After move file to different folder, tags must be deleted from initial folder and added to destination folder
-
Anonymous commented
This is a great workaround for the 255 symbol file name length limit. A lot of my filenames are already long, making tagspaces fairly useless.
A must have!
-
Dokta Bob commented
No seperate file please! But i like the idea with Extended attributes. The only problem with this is probably, that you can't access them accross different plattforms. MacOS doesn't read NTFS attributes...
But you could let the user choose for each folder, what to do: use extened attributes or change the file name. So the user can put files in a folder that that stay on the same plattform and use extended attributes and create another folder for files that will be shared across multiple platforms (windows/android/mac) -
Peter Lehoczky commented
I see this big discussion about which approach should be the "best". I also dont think there is one best solution. One solution can perfectly fit for one person, but doesnt need to fit the needs of another.
I think the best solution would be to give users the choice, for example on first run, you would be asked, if you want to store tags in filenames or in separate hidden folders like SVN does. Of course, there should be some possibility to "convert" already existing tags to other "format".
In my opinion, this would be cross-platform withou problems and would fit needs of much more users. The only downside is it would require more work...
-
Stefan Kuhn commented
Using extended attributes would be ideal for me, as the current solution (renaming files) prevents me from using TagSpaces at all.
However, with the cross-platform scope of TagSpaces, getting extended attributes to work reliably on all major platforms in a JavaScript / Webkit based application might be a huge challenge.
Also, extended attributes in Windows are quite limited (they were added for OS/2 support) and are considered "legacy" by Microsoft. NTFS also supports Advanced Data Streams (ADS) - but then no FAT support, which still is important for USB sticks and card readers - and Microsoft already warns developers that support for ADS might get replaced by something entirely different in future OS versions.
I believe creating separate files for tags and metadata in a hidden folder (similar to what SVN / CVS does) might be the best compromise. It would require considerably less platform specific code.
-
Anonymous commented
Extended attributes looks like the ideal solution!
-
Anonymous commented
Using extended attributes sounds like a fantastic idea, and I would love to see it implemented.
-
Anonymous commented
Actually, there is a fourth option beside meta-files, database and file names: Extended attributes.
Extended attributes are available on the most popular file systems for all platforms supported by TagSpaces: FAT (supported by all), NTFS (Windows), HFS+ (Mac OS X), Ext2-4 (Linux).
Using extended attributes has several advantages with respect to the other solutions (on the model of David Gutiérrez' post):
USING EXTENDED ATTRIBUTES
---------------------------------------------------------+ Changing tags does not change the file name, so hyperlinks / shortcut work as expected.
+ You can move and renames files without breaking tags (direct consequence of the above).
+ It does not "pollute" file names (if you don't like to have tags there, you'll be happy).
+ It solves the problem of the 260 file path limit on Windows, e.g. long file names in deeply nested directories (I don't know about other operating systems).
+ Almost impossible to lose tags by mistake, e.g. if you rename carelessly your files. (Moving files around should be fine also, with the exception of moving them to other file systems that do not support extended attributes, but I suspect that it will not be a common case).
+ You can store "a lot" of data; each file systems let you store at least a few KB (it is not really *a lot* as in "almost unlimited", but it should be enough for tags and tag hierarchies)
+ All systems provide a way to read extended attributes (it is not necessarily easy or straightforward, but it's there out of the box)
+ Does not modify the file's content (e.g. ID3 tags and the like are included in the content)
± Git cannot track extended file attributes (by design), but this can be solved using git hooks. (aka. If you have a solution, you don't really have a problem, right?)
- It is not easy to backup all the tags at once, because they are stored separately (which is the current state anyway).
- Tags cannot be known just by browsing the files in most file explorers (if you like to have tags in your file names, you'll be sad).
---------------------------------------------------------
TL;DR
Using extended attributes to store tags combines almost all the advantages of storing tags in file names, in a database and in meta files, without allmost all of the inconvenients.
-
Duarte Farrajota Ramos commented
From these three I really like the meta files option, I think it is the one with least compromises.
Only bad thing about it is the clutter it creates (theoretically double the amount of files) and the hassle to copy the tag files manually along with the original one.
Although at least Windows used to have some sort of mechanism to do that automatically. I remember copying or moving saved HTML webpages from the internet used to move along the corresponding folder where all the media, data and css was saved automatically. Not sure how this behavior worked internally or if could be extended to make it work with other file types like these tags, but anyway TagSpaces could handle this automatically internally.Ideally I would definitely still prefer seeing this metadata saved inside the very file whenever possible, since many file formats have a way to save metadata in them like id3v1 id3v2 or Ape for music files, EXIF or XMP for images, xml metadata for open office xml based standard, and so on, or fallback to a tag file for unsupported filetypes, preferably an existing standard like XMP sidecar.
I understand this would be a really complex feature to implement since reading and writing these many different standards to several different file types with different storage methods is a lot of work to implement and maintain, but one can dream. :) -
David Gutiérrez commented
I think there are 3 options for storing the tags information (using "meta" files, using a database or storing the information in the filename like we have been doing until now) and each option has different pros and cons, so there isn't a "best choice", the best choice will depend on your intended usage and which features are more important for you.
USING A DATABASE:
-----------------------------------------------------------
+ Changing the tags doesn't change the filename, so hyperlinks (or similar) aren't broken.+ All the information is centralized into a single file, so it's very easy to backup/restore that information without using specialized software, you only need so copy the file into another location.
+ You can store a lot of information (useful for hierarchical tags).
- You need specialized software to access to the database information, so you can't use standard search tools included into modern operating system to search for tags.
- As database files are binary files (and as they are placed into a centralized location), you can't use a version control system to store the changes in the tags of certain files or directories.
- If you move or rename a file without using a special file browser, you will lose the tags information since the link between the tags and the file will be broken. Storing the hash of the file into the database can help you to try to find the new name/location of the file, but it isn't warranted.
USING META FILES (we could have a *.tags file for each file or for each directory):
---------------------------------------------------------------------------------------------------------------------
+ Changing the tags doesn't change the filename, so hyperlinks (or similar) aren't broken.+ You can store a lot of information (useful for hierarchical tags).
+ As "meta" files will probably be text files, they can be used with version control systems very easily.
~ You can retrieve the tags using standard search tools included in modern operating systems... but only if you look at the content of the files (slower), not if you only look at the filename (much faster).
~ You can backup the information very easily (you only need to copy the file and its associated meta file to another location), but if you forget to copy the meta file, you will lose the tags information.
- If you move / rename a file without using a special file browser, you will lose the tags information unless you edit the meta files manually. Storing the hash of the file into the meta files could help to find the new location (or name) of the file, but it isn't warranted.
STORING THE INFORMATION INTO THE FILENAME:
------------------------------------------------------------------------------------------
+ The information is stored in the file, so you can't lose the tags information. That means that you can move and copy the files without fear, but it is possible to lose the tags information if you rename the file manually and you aren't careful.+ You can use standard search tools included in modern operating systems. As you can search by filename (instead of looking at the content of the files), the search will be fast.
- Changing the tags changes the filename, so hyperlinks (or similar) can be broken.
- Some version control systems can detect that you have moved/renamed a file, but storing the tags information into binary files can be a problem in those situations. Certainly, I don't like the risk of filling me repository with a lot of copies of the same binary file only because I've changed the tags associated to that file.
- Because there is a limit in the max length of the path, you can store limited amount of information into the filename (terrible for hierarchical tags). This creates some inconsistencies, because you can store a greater or lesser number of tags depending on the length of the "base" filename or the length of the tag names.
//------------------------------------------------------------------------------------------//
For my intended usage, I think using meta files would be better than storing the tags information into the filename, but I acknowledge there are situations where the later would be more appropriated, so I vote for this feature request as an optional feature (users should be able to select how do they want to store their information).