I just found tag2find (through a post on donationcoder.com forums) and think its a wonderful idea! Like many others, I've been waiting patiently for file system tagging, and after WinFS was taken back out and cruelly murdered, there really wasn't much hope. So its nice to see something being done for home users in this area.
I've signed up for the beta but haven't received the invite yet, so these are just preliminary thoughts based on what I've read. My understanding is that tags are stored in your database and you probably link tags to files using filename+path as the unique id. NTFS change tracking is used to update the tag db if files are moved/deleted/renamed.
Have you considered storing the tags as ADS streams inside the files themselves? NTFS fully supports extensible metadat as I'm sure you know and many programs, such as mp3 and picture tagging (using IPTC/XMP) already store the tags inside objects themselves. I see a number of huge advantages in this approach over a separate db:-
- files contain their own metadata, so no work needs to be done to track them. More importantly, the tag db will never be in an inconsistent state. There actually would be no need for a tag db except to serve as a repository for tag clouds, tracking frequency, related tags etc.
- you could get rid of the initial drive scanning. Tags could be applied as and when needed.
- since tagging is now in a standard format, its possible for other programs to view/expose the metadata. I would like to think that this is the ultimate goal of tagging - not as some addon to existing file organization methods but a fundamentally different metaphor.
However this can be a potential disadvantage if you want to keep the tag functionality proprietary.
- it would be trivial (well, a lot easier), to write an explorer namespace extension that allows viewing and editing tags. Much more powerful stuff can be done in this are - e.g. extensions that are virtual folders based on tags or tag combinations. This would be exactly like what Vista/Spotlight give us, except it wouldn't depend on an indexing service.
- utilities exist to import/export NTFS streams when moving files to a different filesystem, such as CDFS/Fat32. This would solve the problem of supporting external media as well as networked shares.
- Doing this on a lower level is fundamentally a better way because you are not adding another abstraction layer on top of the file system. Basically, I believe WinFS was intended to work in the same way. It also opens up future enhancements such as adding relationships in metadata, writing different kinds of metadata handlers (i.e. the tag could be a more complex object rather than just text, and could perform functions such as redirections).
Of course, there are some rather obvious disadvantages as well -
- the size of each file would increase. Although the total size increase shouldn't be much more than a central db.
- performance may be slower than your approach
- technically, its probably harder to implement. Again, I'm not sure of what you have now so I can't comment on this.
- It would be easy to reverse engineer and use for others. So if your ultimate goal is to have a commercial version for enterprise use, this might not be the best idea

I'll stop rambling now! I'm just very excited by this idea and have been toying with writing something similar myself (as an NTFS file system driver) but never really got anywhere.
Let me know what you guys think.