> we’re ending support for Dropbox syncing to drives with certain uncommon file systems. The supported file systems... and Ext4 for Linux.
Yeah this is not how it works. This is not how any of this works
Yeah this is not how it works. This is not how any of this works
> A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience.
Certainly XFS supports xattr and hence ideally should be supported. I don't know why they singled out ext4. I am running Dropbox on ext4 LUKS encrypted partition and I haven't seen the warning yet.
Lose the most active users, keep the ones paying for something they don't need.
Why? Because there's always exceptions for 'abuse of service' and other exemptions.
The only time something is unlimited is if you do it yourself. Then you only have yourself to lean on.
Because the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. That complicates development quite a bit (because you need to have developers who know the quirks of the file systems) and testing a lot (because all changes have to be tested on all variants, and it becomes multiplicative when a platform has multiple file systems).
But they don't have to maintain a bunch of different filesystems. That's the OS's job. From the application's PoV there shouldn't be any difference between these filesystems, all they need to do is check if the required feature (xattrs) is enabled for a certain FS and that's all.
My guess at the time was that they were using it for cheaper rename detection, using an xattr UUID, instead of using heuristics to compare {inode, btime, mtime, size, name, folder}.
In other words, they would match up the xattr UUID across CREATE and DELETE events to merge them into RENAME events.
Missing RENAME events is pretty bad for the user experience as it can lead to a loss of version history when the file ID changes through the DELETE, CREATE events.
Anyone have any other ideas as to why they would be reliant on xattrs?
It prevents a whole lot of pipeline and concurrency optimizations since it forces you to rehash every file in the change set, before your rename detection algorithm can kick in.
For example, if a user renames a root folder with tens of thousands of descendants, then the hash approach would have poor time-to-first-change-synced latency.
Furthermore, relying on file hashes won't actually work.
A user could have done both a RENAME and UPDATE on the file, since the sync app last ran (you need scanning logic for this, and can't rely solely on inotify). To survive a RENAME and UPDATE, you would then need to compare partial file hashes. But again, it affects latency too much.