I might be in the minority on this, but I think this comes down to a question of "how long are we obligated to stick with a prior unfortunate decision?"
If we were starting over and creating rclone from scratch, I think syncing empty dirs by default would unquestionably be the right decision. Sync is about "mirroring" the src to the dest, and it's not truly a mirror if directories are present on the src but missing on the dest -- simple as that. (Here's my longer rant about the importance of empty dirs, if anyone is interested!)
That said, I also acknowledge that for better or worse, that is not the decision that was made, and rclone has now existed for a long time with the opposite default. So, changing it now would certainly be a change, and any change is going to be unwelcome for some users. There are certainly good arguments for sticking with the prior default, just for the sake of not breaking people's workflows. (I could quibble about why such people are updating rclone without reading the release notes... but it is what it is!)
Three points to consider in favor of changing it:
- Technically speaking, bug fixes are not "breaking changes" (for example, Golang's compatibility promise makes exceptions for bugs and unspecified behavior.) Users do sometimes become accustomed to buggy behavior (see this classic comic!), but that can't be a reason to never fix bugs. I think this one is a pretty close call -- there are good arguments that failing to sync empty dirs was a bug that was finally fixed, and also good arguments that it was an intended design choice.
- For every existing user who will be upset about the change, there could be a future new user who will be confused about the unintuitive default behavior. (I specifically remember tripping over this when I was new to rclone -- it didn't even occur to me that empty dirs might not be copied!)
- The "not breaking things" ship has maybe sailed a bit now, as
v1.66.0did in fact make this breaking change for better or worse, and the question before us now is whether to change it back... (anyone currently usingv1.66.0has already had their workflow break once...should we make them fix it twice?)
Whatever is decided, I do think that @kapitainsky is right that syncing empty dirs and syncing dir modtimes are two separate questions, and decoupling them is helpful. (i.e. even if we decide to revert the empty dir behavior, I think we could still keep syncing dir modtimes by default for non-empty dirs. Dir modtimes is a brand new feature, so there's no backward compatibility to worry about, and file modtimes are already synced by default so doing the same for dirs is consistent.)
TL;DR: syncing empty dirs by default makes more sense to me, but it's been the other way for a long time now, so I understand if the better design choice is outweighed by the priority of not breaking existing workflows. Ultimately, if I need to keep using --create-empty-src-dirs to get my empty dirs, I am fine with that outcome.