4 ms·
I noticed Dropbox started setting their own xattrs on my files a year or two ago if I recall correctly. My guess at the time was that they were using it for ch
by jorangreef 8y ago
I noticed Dropbox started setting their own xattrs on my files a year or two ago if I recall correctly.
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?
- raverbashing 8y agoOr you keep a local db of synced files and compare hashes
- seanieb 8y agoNot if you consider speed and CPU consumption.
- rikkus 8y agoAnd it getting out of sync with reality. Metadata on the files seems much better.
- jorangreef 8y agoYes, on file hashes for rename detection: 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.