Looks nice, but for personal use I don't like the idea of a tool like this changing the file names, and then I see the option in the Pro version to use "sidecar files". Nice! It then brought up another question I have often had with projects like these that start out on Unix like systems and are then available for Windows as well: why do they use dot files on Windows and tell the user to hide them manually, instead of using files with a "hidden" attribute? Part of porting should be adhering to the local conventions, should it not? Since this is not the first time I stumble upon dot files in Windows Explorer I am left wondering there is a real reason for it?
On the one hand, I wouldn't want my filenames to be changed (and in addition, one would likely run into problems with the path length limit, at least on Windows).
On the other hand, using sidecar files would essentially mean giving up freedom to move/rename your files. Sure, you could move/rename the metadata files manually, but it'd be much more work, and you're bound to mess up sooner or later.
I'm not sure how to solve both those points without making the application "own" the files (as e.g. Camlistore does).
NTFS can have additional data streams associated with a file. It's used for stuff like the warnings you get when you try to run an executable downloaded from the Internet. This seems like a perfect solution for me, at least on Windows.
The problem with Alternate Data Streams is interoperability. In many cases, the data will silently be lost when copying between different file systems and/or operating systems. I believe Windows itself will warn you when trying to perform an operation that would discard alternate data streams (for example copying from NTFS to FAT), but many tools would likely silently strip it.
Think of things like any of the cloud drives, bittorrent, screen-sharing or IM software. Are they aware of ADS (or equivalent for that platform). What would the right thing to do be when syncing between platforms that have support, and ones that do not?
It's not just the correct way on windows, it's the correct way on macOS, and any other file system with resource forks or extensible file metadata.
However file metadata is usually pretty poorly understood by most developers (based on a personal sample of my past experiences) and file system resource forks are even less understood...
Perfect is the enemy of good and all that sort of thing ...
Windows even has a standard NTFS metadata field for Tags. You can display it as a column in File Explorer's detail view. You can edit it in the Properties > Details sheet.
Outside of Office sometimes trying to encourage using it to make searching easier and Windows sometimes using it for ID3 tags from audio files, I've never really seen anyone try to use it.
Even worse are Unix utilities that leave dotfiles in every single directory they touch. Just because they're hidden doesn't mean that they're not dirty! Pleas keep your crap restricted to ~/.config, which exists for this very reason.
If you place something in the ~/.config it is not portable, ones you copy your files and folders to a usb stick or sync them with dropbox, you loose the meta data.
Then the app is poorly designed. It should sync metadata over a different channel.
Otherwise you get inconsistent behavior such as metadata being synced when you copy entire folders, but not when you copy individual files. Then you have to rely on even more hacks to get around that, like detecting when a file is copied and automatically copying the corresponding dotfile. Sooner or later you end up with a complete mess.
Probably it's not a high-priority issue, so they didn't implement it yet. Should be easy enough to implement for someone, who uses Windows, if they accept patches. It's a common pattern, when developers think about their environment first.
