You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 9, 2020. It is now read-only.
Right now, the "safe" writer pretty much just drops errors made when attempting to rollback on the floor, but keeps on trying anyway. Quoting @freeformz in #60:
Discussed a bit with @sdboyer yesterday and while I think there are usable bits here, I think it may be a little too defensive. For instance, most errors that will happen during file operations will be IO/file errors and once you hit one of those, it's likely that later ones on the same device(s) / filesystem(s) will also fail. So I prefer the write to temp and fail early bits if possible.
This definitely makes a lot of sense. One possible avenue for improvement in the current implementation would be to look for errors on rollback attempts, and if we encounter some, stop further rollback attempts and just dump a bunch of info to the user about what disk state we think we're exiting in.
Does that seem like an improvement? Maybe there's a better way to go?