VMFS: Read-write option to change tags
Hi Paul,
I've been playing with TMSU the last few days. It's really a great idea! I think it got a few suggestions to make the software really good and usable in lots of situations, I'll be posting them here.
First idea: If the VMFS were to offer an interface to change tags, you could use it over a samba share or from other software. TMSU could actually even be incorporated into NAS software.
One or more of the following options may be useful:
- Next to queries and tags, there could be a directory "files" or something that links to all files on the source location. Like that you could say ln -s files/Photos/vacation.123.jpg tags/country/=spain/ to give mentioned file a tac country=spain. And of course, you could remove tags by using rm tags/country/=spain/vacation.123.jpg . This is the best option, but probably also the hardest to implement. (You could link directly to the file and skip the "files" part, but that was meant to be able to include the file ID.)
- The tagging is kinda similar to adding xattr attributes to a file. In github.com/hanwen/go-fuse I see fuse has xattr support. And Samba supports it to some level. So does PHP, which is often used for NAS frontends. I think that when some program writes a xattr, you could catch it, and use it to create a tag. And map delete to delete, and read to read of course. Unfortunately Windows clients could not use this option, but most Linux/Unix software can.
- Within the mount location, make a control file (for instance $MOUNTDIR/.control) that programs can write to. When they close() the file descriptor, you could read the contents and process them as being commands.
As not everyone may like read-write functions, I would use config variables to make it all controllable.
I thought removing a symlink to remove a tag doesn't work yet. But I just tried, and it does. Don't understand why, yesterday I had the whole tmsu process crash when doing the same.
Hi. Thanks for your suggestions.
(VMFS is a filesystem used by VMware. TMSU utilises a VFS: Virtual FileSystem.)
Some operations are already possible via the virtual filesystem and are described on the wiki. This page also describes why it's not possible (at this time) to tag files using the VFS: the use of file identifiers in the names (necessary to prevent name collisions) makes it difficult to implement this as you would have to know what the identifier will be when linking the file. I could allow the files to be linked without identifier but then, subsequently, the user (or program) would have to know
There is already an issue for using extended attributes. I have avoided them to date because I wanted a cross-platform solution and had also read that incomplete or missing support of extended attributes by various pieces software can lead to the extended attributes being inadvertently dropped when files are edited or otherwise operated upon. However, I'll leave this issue open as there is surely some level of extended attribute support that could be offered.
I don't like the idea of a hidden file in which you can pipe commands. For a program to have intimate knowledge of the TMSU commands, it may then as well call into TMSU API (or embed TMSU within it).
Thanks for the quick response :-)
The identifier issue I tried to fix with my suggestion to create a "files" directory. All files in there do already have the identifier in their name. :-D
The pipe idea: the kind of programs I think to usually use it are web applications written in higher languages such as PHP. I think of a NAS frontend. And applications on the other side of an Samba connection. Both cannot use the TMSU CLI (well, webapps can, but shouldn't) nor embed TMSU. I don't see an API anywhere? The pipe was meant as an API for basic commands.
I'll look into the xattr possibilities: hooking these may just work.
The other too ideas I think are to niche/fiddly to be worth the effort.