In distributions that use GLib extensively (Ubuntu, Mint, anyone using Gnome), the .cloudf files can’t have a custom mime-type set, and therefore, as far as I can tell anyway, can’t have a custom default handlers associated with them. Because they’re 0 length. It seems that GLib hard codes the mime-type for 0 length files to text/plain.
See: https://git.gnome.org/browse/glib/tree/gio/glocalfileinfo.c#n1241 for context.
This is a problem because I’d really like to write a wrapper tool that syncs a file when I click on it in my file explorer, and then opens the appropriate application on the newly synced file. And, it’ll be a problem anyway if ya’ll want to build a GUI for Linux at some point anyway
I’m rolling up my own desktop integration with the Nautilus file manager of Ubuntu / GNOME, and I’m running into a weird limitation of Nautilus (actually “xdg-open”, so it may impact other distros and Linux desktop environments): All files of 0 bytes are always treated a “text/plain” (or “inode/x-empty”), so opening them will always invoke a text editor.
For example, let’s say you run “touch a.xml”, then “xdg-open a.xml” or double-clicking the file on the desktop will open a text editor, whereas with “echo a > a.xml” the web browser (or whatever handles text/xml) will be used.
Now, I wrote some dumb script that periodically runs “echo a > file.cloud” on all *.cloud or *.cloudf files that are 0 bytes, but this is a clumsy hack, and if you ever want to implement a Linux desktop integration GUI you’ll run into the exact same issue.
So, could there be an option for odrive-agent to automatically insert a dummy single byte of data in every cloud or cloudf file it creates?
