Workspaceops rework read folder

[touilleMan]

• API change
• Fuse changes
• WinFSP changes

Closes #5820
Closes #6491
Closes #6914

[AureliaDolo]

I don't quite get why you would want that ? Is it to have a real human person check that the new field does not interact with the merging process, or to adapt the merging process ?

Maybe annotating LocalFileManifest with non_exhaustive could do the trick

[touilleMan]

Consider the following:

struct Data {
  updated: DateTime,
}

fn merge(local: Data, remote: Data) -> Data {
   remote.updated = max(local.updated, remote.updated);
   remote
}

Then we introduce a new created field

struct Data {
  created: DateTime,
  updated: DateTime,
}

The code will compile fine event if we haven't updated merge (typically we should have added a line like remote.created = min(local.created, remote.created)).

This is an issue given this merge function is easy to forget to update:

• it is in a different file
• its tests will most likely just ignore the new field

On the other hand, if the merge function is implemented with exhaustive de-structuring, it will fail to compile any time a new field is added. Hence forcing the developer to have a look at this part of the code.

This is a pattern we also use in the CRC code of the testbed. Nobody knows about this piece of code and nobody cares... but if a structure changes and the CRC starts being wrong, we will have very hard time understanding why the tests start becoming randomly wrong (as client and testbed server code may end up with different data with the same CRC...)

Regarding non_exhaustive, its point is to forbid exhausting destructuring, which is the opposite of what we want here ;-)

[AureliaDolo]

Thanks, so we could put that behind a debug_assert to make sure that it won't be present during runtime ?