During last days I was thinking about allowing Tagsistant to index files outsite its internal archive. There are a lot of reasons to do that.

First of all, users does not understand Tagsistant internals, so are not supposed to understand that a file tagged by Tagsistant will be duplicated inside its internal storage, wasting disk space if an external copy still survive.

Second: that will solve a lot of issues about improper file deletion (perhaps before a copy operation has been completed). That's a subtle problem to track down.

And that will also allow for duplicated files inside Tagsistant. Yes, I've said that. I'm working on it.

So far, two files can't share the same name inside Tagsistant. That's because: 1. all the files are stored inside its internal archive and 2. when Tagsistant forge the ouput of a readdir() call, each filename can be listed only once.

So, the first problem can be solved indexing files in their original position. But the second one? How could be solved? After thinking on it for a while, I've eventually decided that adding an index number to the filename is the only solution. That index number will probably be the SQL ID field that identifies each file in the backend. So if two files are called phonenumbers.txt, the first will be 000023.phonenumbers.txt and the second one will be 000106.phonenumbers.txt.

I'm pretty sure that the best strategy is to use hardlinks to refer to external files. That has a lot of benefits and one draw back.

The drawback is that only files contained in the same filesystem hosting the backend can be tagged. That's because hardlink in many operating systems (including Linux) can be established only in the same filesystem of the original one.

But the advantages are many. The user can move the file across the filesystem and the file will still be tagged. Even if the user moves the file in another filesystem, the tagged copy will remain inside Tagsistant. The process of tagging a file will be very fast, because no copy will happen. So a lot of advantages.

The path_resolution.c file and the SQL schema (which alse needs a lot of rethinking and would benefit from the addition of indexes and foreign key) will be adapted to implement the new design.

I would just hear from you before starting the rewriting. What do you think about that?