-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prevent the overwrite of existing mpq files #7674
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you still save with this...?
What should happen as a result of this change is... The game will still crash, but it won't completely overwrite the save file. Still not ideal, since the player will lose progress since their last save, but it's a whole lot better than losing the whole character. |
So the game deletes the file before writing the new save? And sometimes the file sync tries to restore the file at the same time? Should we instead overwriting the existing file or write to a temporary file and renamed it at the end? |
Unfortunately, I can't really answer that question for you. I don't understand how it's even possible for OneDrive to interfere with the My best guess is that maybe OneDrive is somehow taking an exclusive lock on the folder containing the file so that it can't be used to check for the existence of files within. At the very least, it makes some sense to me for a tool that does file synchronization to maybe want to ensure that the folder can't be changed while it's in the middle of scanning for changes.
As you can see by the fact that the save file in #7672 only contains
In either case, it requires more file I/O operations than the current mechanism for updating the existing MPQ file, which means you're probably actually more likely to encounter an unrecoverable conflict between the game client and OneDrive. Instead, I would recommend referencing the .NET Framework implementation of Another alternative I would recommend would be to skip That said, regardless of what we do, if we are completely unable to get write access to the file, there's probably no other reasonable alternative besides |
If possible we should probably request an exclusive lock on saves while the game is running. |
Lifted from pionere's fork: pionere@7866861
He simply adds the
x
flag to indicate thatwb
should not overwrite existing files. This should indeed prevent the issue of save files being wiped out. It might still be a good idea to handle error messages fromPathFileExistsW()
more explicitly, but this change seems like an obvious improvement to me.This resolves #7672