[0.17.36] Save crash: Util.cpp:83: last_write_time(p): invalid argument:

[Qon]

Was saving a file. But it failed. Log attached. Got an error message, first in a factorio styled popup, but without the regular request to send the log. Then I pressed the save button (in esc menu) to try to save again and then I got the same short error message in a windows dialogue box and Factorio was no more.

[Qon]

So I restarted Factorio and it happens again as soon as I press "load game" in the main menu, before I even see my save file list.

[Qon]

I removed my recent savefiles from the save folder and pressed load and it worked again. And when I put the savefiles back again I didn't get the error. So I can play again at least. It happened every time until I did that though.

[Qon]

When I temporarily removed this attached file I could finally see my save file list again.

[TruePikachu]

I'm unable to reproduce this issue at all without mods.

[Qon]

I'm unable to reproduce it with mods now. It crashed every time I pressed load game (5~times in a row) until I removed that savefile from my save folder. But now that I put it back again there's no longer any issue. The problem might be in some metadata file or cache that keeps track of savefiles (if such a file exists) which would mean the issue isn't in the savefile I uploaded.

[kovarex]

Hello, there is no metadata, just the save files.
The error almost looks like a permission issue (which might have been solved by moving the file there and back).

I would just move it to pending, since I don't really know what to do with the bug now.

[TruePikachu]

Oh wait, that's the function in std::filesystem, isn't it? That would make sense for the error message.

Going by my local library sources in VS2017, it results in a call to GetFileAttributesEx. Assuming the trivial case where the target isn't a reparse point, the only "uncommon" error condition I can see listed in MSDN is vague wording regarding if the file is open for transactional modification (which prevents any other threads from opening the file for modification until the transaction is committed -- even though GetFileAttributesEx shouldn't need to modify the file in the first place). It does look like a permission issue of some degree, though it might have been prompted by an external process (e.g. an antivirus).

@Qon, what AV (if any) do you run?

[Qon]

I had recently copied that file to another folder when the error started. But the copying process had completed and I was uploading the copy. But maybe something went wrong in the filesystem and it forgot that it was no longer being copied? Browsing save files (I presume) and copying (on source) are both pure read actions so there shouldn't be a problem but I didn't write NTFS so maybe it's not good code q:

Avira Antivirus.

[TruePikachu]

I was uploading the copy

What program? If it was something like onedrive, it's known that it fully locks files that are being synchronized. I'd suspect several other programs (including web browsers in some contexts) also would want to lock the file during an upload, but there shouldn't be any reason to prevent read access.

EDIT: Avira is known to also cause issues with regard to file locking, which is something entirely outside Factorio's control.

---

Probing the file's last write time is supposed to also be a purely read-only operation, and (possibly sans access time) copying a file is also a read-only operation on the source file.

Sometimes, I wish Windows could give better error messages.

[Qon]

I was uploading with Firefox. But it was the copy that I was uploading so Firefox never touched the file that Factorio reads.