Factorio Forums

Since updating to version 0.11.17 i have a problem where the game locks up when i click the save button in the esc menu.

eventually it crashes with the following error message

boost::filesystem::read_symlink: The process cannot access the file because it is being used by another process: "c:\Users

Im running windows 7 64bit service pack 1 installed on a solid state drive with my "Users" directory shunted to a secondary drive using a junction.

Autosaves work fine its just when i actually click the "Save Game" button in the menu the button looks depressed but nothing else happens until the error message pops. Then the game immeaditly closes when the ok button is pressed on the error message

im fairly sure this has only started happening since 11.17 but i will roll back and check with an older version tommorw.

from the factorio_current.log

UPDATE:
Rolled back to version 0.11.16. save button works correctly. i.e. no bug

updated to 0.11.17 again and bug returns..

I don't know what the Junction is, but according to wiki, it can only poin to a local volume: http://en.wikipedia.org/wiki/NTFS_junction_point

So I guess that the error is in your setup.

I don't know what the Junction is, but according to wiki, it can only poin to a local volume: http://en.wikipedia.org/wiki/NTFS_junction_point

So I guess that the error is in your setup.

Is there a reason at all to use junction points and not symlinks for nonsytem things?

From Wiki
re Junctions
An NTFS junction point is a symbolic link to a directory that acts as an alias of that directory.

Re symlinks and their difference to junctions
Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives

As the drive i'm pointing to is on my local machine and not a network path the correct and (Microsoft) recommended method is to use a junction. In addition i believe i attempted to use basic symlinks when i first set this up (over 2 years ago now) and the windows os wouldn't accept the symlink for the user directory, hence i was forced to use a junction.

All this however is beside the point. The problem is that every other program i run has zero issues with this setup and factorio has no issues up to version 0.11.16

In 0.11.17 something has been changed causing this problem with saving to occur

Cheata wrote:From Wiki
re Junctions
An NTFS junction point is a symbolic link to a directory that acts as an alias of that directory.

Re symlinks and their difference to junctions
Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives

As the drive i'm pointing to is on my local machine and not a network path the correct and (Microsoft) recommended method is to use a junction. In addition i believe i attempted to use basic symlinks when i first set this up (over 2 years ago now) and the windows os wouldn't accept the symlink for the user directory, hence i was forced to use a junction.

All this however is beside the point. The problem is that every other program i run has zero issues with this setup and factorio has no issues up to version 0.11.16

In 0.11.17 something has been changed causing this problem with saving to occur

One of the things that I changed is, that Factorio is using unicode paths in 0.11.17 on windows. But I have really no idea why could it cause trouble like this. I might try to take a look at it in the next major version.

yea the strange thing is it only seems to affect the clicking of the save button in the menu. Load game (which probably uses similar code as far a locating paths is concerned) works fine, auto save works fine, even saving maps in the map editor works fine.

it appears that its only when the save button tires to find the save file directory that it fails.... Weird

Please let me know if you would like further tests done at my end

hello i would also like to say i am having the same problem with saving, game hangs and then crashes when trying to save

the weird thing is that it only seems to happen with the exe download, i also have a zip file version which i use to play mods and i can still save fine on it, both are updated to 0.11.19

Could this be related to this? https://svn.boost.org/trac/boost/ticket/10900

Rseding91 wrote:Could this be related to this? https://svn.boost.org/trac/boost/ticket/10900

Interesting reading and could certainly be related.

However keep in mind the fact that it only occurs when clicking the save button and not on every other directory parse the game performs points to a key difference in that particular function

I have the same problem. Autosave and load works fine, but not manually clicking the save button. I use the same setup as Kovarex and the problem occurs for ms installer as well as the zip. Please fix this.

just thought id let you know this also occurs when clicking the save replay button at the end of a game... not something i normally do so i didn't notice it till just now

I am also experiencing this issue. c:\users is a junction on my setup, which seems to work fine for every other program, and on factorio 0.10 - not sure which .11 version broke this.

Autosaves seem to work fine, and I just wait around a minute if I need to save. Happy to help debug the issue, love the game!

mediocretes wrote:I am also experiencing this issue. c:\users is a junction on my setup, which seems to work fine for every other program, and on factorio 0.10 - not sure which .11 version broke this.

Autosaves seem to work fine, and I just wait around a minute if I need to save. Happy to help debug the issue, love the game!

I have Factorio on a normal directory, and autosave would consistently fail when I have a particular GUI open. I can't remember what it is at the moment, but I'll update this once I remember. I think it's when I am dragging the deconstruction planner but not yet release the mouse. Something very specific like that.

johanwanderer wrote: I have Factorio on a normal directory, and autosave would consistently fail when I have a particular GUI open. I can't remember what it is at the moment, but I'll update this once I remember. I think it's when I am dragging the deconstruction planner but not yet release the mouse. Something very specific like that.

That sounds like a different issue, you might want to start a separate bug report when you work out the specific circumstances

Problem continues to occur in .12.1

I can confirm this problem is still present in 0.12.2 and 0.12.3 (same error regarding the boost C++ library). I am incapable of saving my games manually (only auto-save works). I use a junction to link C:\Users to D:\Users, a setup that I have been using for several years on a Windows 7 machine (which has personal server software and code running on it, a setup the average person would not have) without any issues ever except for this game; the junction is to make room for the OS and often used software on a SSD and keep my user files separately located on a larger HDD.

I purchased the game back in January and was having no problems back then with saving but have been too busy to really get into the game until a couple of days ago, which is when I came across this problem.

(Edit) Workaround:
1. Make sure the game has write access to the install directory (my game is installed at D:\Games\Factorio); in other words, avoid installing to Program Files.
2. Temporarily rename the shortcut directories in the install directory: config, mods, saves (I just append an underscore to them).
3. Create real directories of the above three in the install directory.
4. Move the contents of the shortcut directories into the new real ones.
5. Delete the shortcuts.
6. Open "config-path.cfg".
7. Change "config-path=__PATH__system-write-data__/config" to "config-path=__PATH__executable__\..\..\config"
8. Change "use-system-read-write-data-directories=true" to "use-system-read-write-data-directories=false"
*** Continue if you have the file in step 9 (should be present if you have run the game at least once)***
9. Open "config/config.ini" or alternatively you can delete this file and skip step 10 but lose your settings
10. Remove the entire section under [path], should only have settings for read-data and write-data.

This will force all configs, saves and mods to be located in the actual installation directory instead of appdata under your user's directory.

stevehead wrote: the junction is to make room for the OS and often used software on a SSD and keep my user files separately located on a larger HDD.

exactly the setup i'm using

stevehead wrote:
6. Open "config-path.cfg".
7. Change "config-path=__PATH__system-write-data__/config" to "config-path=__PATH__executable__\..\..\config"
8. Change "use-system-read-write-data-directories=true" to "use-system-read-write-data-directories=false"
*** Continue if you have the file in step 9 (should be present if you have run the game at least once)***
9. Open "config/config.ini" or alternatively you can delete this file and skip step 10 but lose your settings
10. Remove the entire section under [path], should only have settings for read-data and write-data.

This will force all configs, saves and mods to be located in the actual installation directory instead of appdata under your user's directory.

Thanks for the work-around.
Having read this i now understand why the zip version works while the self contained installer doesn't
I originally attempted a similar work around but didn't realize there were config files that needed to be changed and only removed the links and copied the files across, didn't work of course.

Ill try the full work-around next time I run the game.

Cheata wrote: Having read this i now understand why the zip version works while the self contained installer doesn't

I completely overlooked the ZIP version when I got the game. I guess that would be another "workaround" by just using that instead. I may just end up using that instead of the installer as I prefer games/software installation to be more or less isolated from the OS whenever possible.