News for hackers. Stuff that matters.
Re:Rewriting the heart of our sync engine by GordonS on Tuesday March 17, 2020 @07:38PM (#22611866)
For NTFS volumes (basically all Windows volumes), you could use the change journal to eliminate that painfully expensive startup check of all files - that would be huge for Windows users.

Also, have you previously explored the possibility of using the NTFS change journal, and if so, what challenges did you face? (I don't mean to come across negative; I'm genuinely interested to learn why you didn't use this a decade ago, since there must be a reason).

Re:Rewriting the heart of our sync engine by rbtying on Tuesday March 17, 2020 @08:37PM (#22612357)
As I recall, this was investigated at one point on Sync Engine Classic and is definitely a thing that folks were thinking about for Nucleus, for pretty much exactly this reason.

The biggest challenges with this kind of work (not specific to the USN journal) are in the lack of reliable cross-platform support for features which can be shimmed to look similar. The more unique the code path, the harder it is to test en masse.

It's also the case that the execution environment on Windows machines tends to be very diverse due to a long history of backwards compatibility and the ability to set complex domain policies -- Dropbox strives for a good user experience, and "go talk to IT to have them change this setting" is rarely one of those.

disclaimer: worked on sync at Dropbox; don't work on it anymore; don't have current context