Make placeholder files larger than 0 bytes



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: 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 :slight_smile:

Linux desktop Integration: Making cloud and cloudf files non-empty

Thanks for the feedback @bcs. We will keep this in mind for future enhancements.


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 >” 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?


This looks like the same issue as the forum post Make placeholder files larger than 0 bytes .


Thanks @benad. I added your comments to the original thread