• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[Solved] Map Could Not Be Opened

Status
Not open for further replies.
Did you check your Warcraft III/Maps/Test folder? There might be a chance that your map is still there.
I was using the WE from patch 1.30.1, so there is no Test folder there.
Otherwise, if you're using JNGP, you can look for it inside the "backups" folder.
Sadly I was just using the normal WE.
 
Level 8
Joined
May 21, 2019
Messages
435
Did you ever send the map to anyone or take a copy?
I have been in this situation before. Whenever I work on a map, I always have a copy stored on a cloud server or etc.
Hindsight is always 20/20, so it will not help you now, but life has a way of teaching lessons the hard way. :/
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,201
Welp, I was working on a map today.. electricity got shut for a moment after saving my map, I'm sure it was entirely saved before the crash! But now when I open the map it says "Main map file could not be opened"...
Yes it was fully saved. No the map file was not fully written to disk yet.

To improve application responsiveness and write performance modern OS will buffer writes to physical devices. This allows writing I/O calls to return near instantly for better application write performance and also for the physical device to be fed write commands efficiently for improved device performance. It also allows multiple small writes to me merged into single bigger writes potentially reducing the number of write commands required allowing the physical device to operate more efficiently. The caching nature also means that frequently rewriting data may generate fewer write commands and use less write bandwidth.

Of course the obvious problem is that if power fails between the time the application thinks the data has been written and the time the file buffer is written to the physical device then the file data will be lost and the file will become corrupt. When writing an application one can mitigate this to some extent by disabling buffered writes so that write calls only return when written to the physical device. However this mitigation is often ineffective since it may not factor in that physical devices themselves can have memory buffers to improve write performance and so prematurely signal the data as having been written.

The duration that the data is buffered is based on the amount of free system memory available, the amount of data being written and the write performance under the appropriate characteristics of the physical device. Saving a map file to a typical modern SSD with tons of free space might result in the buffer lasting only a second or so before it is written to non volatile storage. On the other hand saving a map file to a mechanical drive while writing out gigabytes of game files on a system with 16 GB or more of memory might result in the buffer time being several minutes in duration.

When a computer is shutdown, restarted or sent to sleep then by the time the power state changes all buffered writes will have been written out to non volatile storage. Additionally one can use a tool like RAMMap to explicitly purge the file cache contents and hence force all cached/buffered writes to be written out as soon as possible.
 
Did you ever send the map to anyone or take a copy?
No.
I have been in this situation before. Whenever I work on a map, I always have a copy stored on a cloud server or etc.
Well, it's like.. when I work on a map, I completely forget to make backups coz I'm often too drown in WE...
Hindsight is always 20/20, so it will not help you now, but life has a way of teaching lessons the hard way. :/
Yeah.. I guess I have to rework the parts I had lost anyway.
Yes it was fully saved. No the map file was not fully written to disk yet.

To improve application responsiveness and write performance modern OS will buffer writes to physical devices. This allows writing I/O calls to return near instantly for better application write performance and also for the physical device to be fed write commands efficiently for improved device performance. It also allows multiple small writes to me merged into single bigger writes potentially reducing the number of write commands required allowing the physical device to operate more efficiently. The caching nature also means that frequently rewriting data may generate fewer write commands and use less write bandwidth.

Of course the obvious problem is that if power fails between the time the application thinks the data has been written and the time the file buffer is written to the physical device then the file data will be lost and the file will become corrupt. When writing an application one can mitigate this to some extent by disabling buffered writes so that write calls only return when written to the physical device. However this mitigation is often ineffective since it may not factor in that physical devices themselves can have memory buffers to improve write performance and so prematurely signal the data as having been written.

The duration that the data is buffered is based on the amount of free system memory available, the amount of data being written and the write performance under the appropriate characteristics of the physical device. Saving a map file to a typical modern SSD with tons of free space might result in the buffer lasting only a second or so before it is written to non volatile storage. On the other hand saving a map file to a mechanical drive while writing out gigabytes of game files on a system with 16 GB or more of memory might result in the buffer time being several minutes in duration.

When a computer is shutdown, restarted or sent to sleep then by the time the power state changes all buffered writes will have been written out to non volatile storage. Additionally one can use a tool like RAMMap to explicitly purge the file cache contents and hence force all cached/buffered writes to be written out as soon as possible.
So it was just not saved to the disk. Actually, the accident happened immediately the moment after the map was saved, so I guess the time was much more needed to perform a complete write especially considering the fact that my PC is a bit too old! The free space was also not too much.
A detailed explanation as always, my thanks!

I'll mark this thread as "Solved" then.
Thank you, guys!
 
Status
Not open for further replies.
Top