GameMaker [SOLVED] Unable to write file to program_directory with sandbox disabled

I'm having trouble writing files to the directory where the exported game is located. I disabled the file system sandbox via the Windows export settings. The program is located in a folder on the Desktop. I have cleared the project cache and that did not work. I have tried running the program as an administrator and that did not work. The following is the code I am using:

Code:
var f = file_text_open_write(program_directory + "log.txt");
file_text_write_string(f, program_directory + "Maps\\asdf.bin");
file_text_close(f);
The program writes files to %localappdata%\game_name\ instead of the expected directory, "D:\DESKTOP2\Dungeon Mapper\". I have tried replacing (program_directory + "log.txt") with ("log.txt") and that did not change anything. log.txt contains the following string:
Code:
D:\DESKTOP2\Dungeon Mapper\Maps\asdf.bin
This shows to me that the program can find the intended write directory, but is not writing to it for some reason. Does anyone have any idea what could be causing this and how to fix it?
 

Yal

šŸ§ *penguin noises*
GMC Elder
Does it work if you use forward slashes instead of backslashes as directory separators, to get rid of the backslashes being interpreted as escape characters? There's a thing called Leaning Toothpick Syndrome when you have multiple tiers of backslashes (if your \\ gets passed to another program, it might be a \ in there, which causes the interpreter in THAT program to use it as an escape instead of a literal, which means you'd need a \\\\ in the original string... and this goes on infinitely in theory)
 
Does it work if you use forward slashes instead of backslashes as directory separators, to get rid of the backslashes being interpreted as escape characters? There's a thing called Leaning Toothpick Syndrome when you have multiple tiers of backslashes (if your \\ gets passed to another program, it might be a \ in there, which causes the interpreter in THAT program to use it as an escape instead of a literal, which means you'd need a \\\\ in the original string... and this goes on infinitely in theory)
It does not matter if I use / or \\. I have tested both.
 

TsukaYuriko

ā˜„ļø
Forum Staff
Moderator
Does that include the backslashes returned by program_directory? The path you posted in the opening post includes single backslashes, so they may end up escaping whatever is after them. Try writing the full path manually with only forward slashes to verify.

That aside, does the game have OS-level permissions to write to the folder you're trying to write to?
 
Does that include the backslashes returned by program_directory? The path you posted in the opening post includes single backslashes, so they may end up escaping whatever is after them. Try writing the full path manually with only forward slashes to verify.

That aside, does the game have OS-level permissions to write to the folder you're trying to write to?
Back/forward slashes are not the issue here. If I've tried something, assume I've tried both ways because I did. I would assume the game has OS-level permissions because manually changing the path just worked. This only works when running from GMS2. Running from the .exe appears to make it act as though it was still sandboxed.

EDIT: Both the IDE and the runner are up to date. IDE v2.2.3.436 and Runner v2.2.3.344
 
Last edited:
Bump.

Still have no idea what could be causing this. To clarify my previous statement, the following both work as intended while running the game through the IDE, but not when run as an executable.
Code:
var f = file_text_open_write("D:\\DESKTOP2\\Dungeon Mapper\\log.txt");
file_text_write_string(f, program_directory + "Maps\\asdf.bin");
file_text_close(f);
Code:
var f = file_text_open_write("D:/DESKTOP2/Dungeon Mapper/log.txt");
file_text_write_string(f, program_directory + "Maps\\asdf.bin");
file_text_close(f);
 

rIKmAN

Member
I can confirm that I've also had issues with writing to the game folder when running from executable.
I didn't look into it as I was just testing saving/loading routines so I just changed the path to dump on the Desktop which worked fine.

Might be worth filing it as a bug with your test project attached as I've seen quite a few posts saying the same thing so something seems wrong.
 
I can confirm that I've also had issues with writing to the game folder when running from executable.
I didn't look into it as I was just testing saving/loading routines so I just changed the path to dump on the Desktop which worked fine.

Might be worth filing it as a bug with your test project attached as I've seen quite a few posts saying the same thing so something seems wrong.
Thanks. I wanted to make sure it was something wrong with GMS before submitting a report. Just tested the same program on a fresh install of Windows, and the results were identical. I filed a bug report. I will bump this post again whenever I get any updates on the situation and will mark it solved when the bug is ironed out.
 

rIKmAN

Member
Thanks. I wanted to make sure it was something wrong with GMS before submitting a report. Just tested the same program on a fresh install of Windows, and the results were identical. I filed a bug report. I will bump this post again whenever I get any updates on the situation and will mark it solved when the bug is ironed out.
Did you hear anything back regarding this yet?
I checked Mantis but couldn't see anything related to this on there.
 
S

Sam (Deleted User)

Guest
I have to update File Manager still so that it will do the same thing. But my free dialog Module extension which includes a newer version of File Manager overrides program_directory with the correct path. http://marketplace.yoyogames.com/assets/6621/dialog-module

You can just delete the dialog module extension from the resource tree if all you want is the file manager extension that comes with it.
 
Did you hear anything back regarding this yet?
I checked Mantis but couldn't see anything related to this on there.
Not even an email saying "we received your report". Maybe I submitted the report in the wrong place. Where would be the proper place to report bugs?
 

rIKmAN

Member
I have to update File Manager still so that it will do the same thing. But my free dialog Module extension which includes a newer version of File Manager overrides program_directory with the correct path.
Have you confirmed program_directory returns an incorrect path?

I've just been playing around with working_directory and am getting similar issues with trying to copy files to the same directory as the exe.

The source file is valid (and the path uses working_directory) as I can copy it to other locations (ie. the desktop) if I write the path directly - but hardcoding the path to it still won't copy to the exe folder which is ON the desktop.

@nacho_chicken
You can use the Help menu in the IDE or open a ticket on the help site.
Both should be fine to use and go to the same place.
 
S

Sam (Deleted User)

Guest
You can see the value with get_string and open the folder by copying the path into a file manager, which is what I've done to confirm it (for years now)

Edit: ah, you said "was I able to confirm it returned the incorrect path". I've never had it not work before, so I couldn't tell you whether it ever stopped working at some point. I can try it again if that helps
 

rIKmAN

Member
You can see the value with get_string and open the folder by copying the path into a file manager, which is what I've done to confirm it (for years now)
Did you report it, and if so what did they say?

There is definitely something iffy going on, like nacho says it's like the sandbox is still on when trying to use the exe folder whether I use working_directory or directly hardcode the path to the exe folder on the desktop (or elsewhere).

I know the source filepath is correct as I can copy it elsewhere on multiple drives using multipel hardcoded paths.

I thought the issue may be the slashes not being escaped in the path returned by working_directory, but if that was the case then copying it to other locations from a source path built using working_directory wouldn't work either.
 
S

Sam (Deleted User)

Guest
I'm actually in the middle of doing something right now, but I'll try turning off the sandbox in an empty project with the latest ide and runtime before the night is over (its roughly 10pm where I live)
 

rIKmAN

Member
I'm actually in the middle of doing something right now, but I'll try turning off the sandbox in an empty project with the latest ide and runtime before the night is over (its roughly 10pm where I live)
Yeah OK let us know how you get on trying to copy a file into the exe folder from elsewhere (or file_copy a file in there etc).
To confirm - I am using the latest IDE + Runtime and the sandbox is off.
 
S

Sam (Deleted User)

Guest
Sorry, I got to a stopping point. So what should I test, just to confirm?

From what I gather I should:

- Test for the return of program_directory and working_directory both with and without my extension with get_string's second argument.

- test file_copy with sandbox off with and without my extension

Is that all? Or is there more you guys want me to do? I just booted into Windows and am trying those for now

Edit: a little bit random but mmmm this peach tea is sooo good
 

rIKmAN

Member
Sorry, I got to a stopping point. So what should I test, just to confirm?

From what I gather I should:

- Test for the return of program_directory and working_directory both with and without my extension with get_string's second argument.

- test file_copy with sandbox off with and without my extension

Is that all? Or is there more you guys want me to do? I just booted into Windows and am trying those for now
Not sure about what tests nacho wants you to do, but for me just try using the native GML functions with the sandbox off to try and copy a file INTO the same folder as the game exe.

Using file_copy():
I used working_directory in the source path, and again in the destination path - this failed.
I also tried hardcoding the destination path to the exe folder on the desktop - also failed.
I tried using working_directory in the source path to copy a file from the exe folder onto the desktop - this worked.

I guess generally just try and copy / create a file in the same directory as the exe after you have compiled and exported the project and see if it works.

Thanks for taking the time to test, I appreciate it.
 
S

Sam (Deleted User)

Guest
Updating GM. Weird, I thought I had the latest version. I guess they rolled out a new update a lot quicker this time.

Will edit my post with the results. This thing is taking a while.
 
Did you report it, and if so what did they say?
It was just a generic "your ticket has been created" email.
Your ticket has been created and is now in the support queue.

Your ticket number is: XXXXXX

One of our Customer Service Technicians will be with you as soon as possible.

Thanks
YoYo Games
Not sure about what tests nacho wants you to do
I honestly can't think of anything that needs to be tested further. My own tests were sufficient for me.
 
S

Sam (Deleted User)

Guest
Code:
get_string("working_directory", working_directory); // returned C:\Users\owner\Desktop\test\
get_string("program_directory", program_directory); // returned C:\Users\owner\Desktop\test\

file_copy("C:\\windows\\system32\\notepad.exe", working_directory + "working_notepad.exe"); // did nothing
file_copy("C:\\windows\\system32\\notepad.exe", program_directory + "program_notepad.exe"); // did nothing
my extension however can fix this in the meantime. it's not ideal but it's something. So program_directory and working_directory are not broken. The source of the problem is breaking the sandbox is impossible without an extension again it appears.
 

rIKmAN

Member
The source of the problem is breaking the sandbox is impossible without an extension again it appears.
But if that was the case I shouldn't be able to copy files from the exe directory to the Desktop, or my D:, E:, F: or G: drive etc which works fine when the sandbox is turned off.

Thanks for testing again, it definitely appears something is wonky with it somewhere.

@nacho_chicken if you don't hear anything back shortly update this thread and I'll also file a bug report - although I have an unrelated bug report outstanding myself which is a month old with no reply so not sure how much difference it will make haha. Can't hurt though.
 
L

Lonewolff

Guest
Just tested and disabling the sandbox is working fine.

Code:
a = file_copy("C:\\windows\\system32\\notepad.exe", working_directory + "notepad.exe");
b = file_copy("C:\\windows\\system32\\notepad.exe", "d:\\test\\notepad.exe");
c = file_copy("C:\\windows\\system32\\notepad.exe", "y:\\notepad.exe");
a - fails
b - works
c - works

Seems to be a bug isolated to 'working_directory'.

Note: working_directory is being mapped to 'Y:\file_io_test_2EC2AB55_VM' for me, while running from GMS. Just making it clear that Y drive isn't one of my normal drives, it is the temp drive created by the IDE when the program is executed.
 
S

Sam (Deleted User)

Guest
Just tested and disabling the sandbox is working fine.

Code:
a = file_copy("C:\\windows\\system32\\notepad.exe", working_directory + "notepad.exe");
b = file_copy("C:\\windows\\system32\\notepad.exe", "d:\\test\\notepad.exe");
c = file_copy("C:\\windows\\system32\\notepad.exe", "y:\\notepad.exe");
a - fails
b - works
c - works

Seems to be a bug isolated to 'working_directory'.

Note: working_directory is being mapped to 'Y:\file_io_test_2EC2AB55_VM' for me, while running from GMS. Just making it clear that Y drive isn't one of my normal drives, it is the temp drive created by the IDE when the program is executed.
I actually exported the game to my desktop, so that would indicate it doesn't work regardless of where the working directory is. (Even if you have write access)
 
Last edited by a moderator:
L

Lonewolff

Guest
I actually exported the game to my desktop, so that would indicate it doesn't work regardless of where the working directory is. (Even if you have write access)
Yep, agreed. I did see that you were running an exported program too. So that would back up the working_directory as the culprit.

Maybe internally something is going odd and it is taking the '\'s in the working directory string as an escape code or something. I bet if you hard code the working directory path it will work. Doesn't help long term obviously, but would give more information to feed back to YYG.
 
Yep, agreed. I did see that you were running an exported program too. So that would back up the working_directory as the culprit.

Maybe internally something is going odd and it is taking the '\'s in the working directory string as an escape code or something. I bet if you hard code the working directory path it will work. Doesn't help long term obviously, but would give more information to feed back to YYG.
Hard-coding the directory path still fails for me.
 

rIKmAN

Member
Yep, agreed. I did see that you were running an exported program too. So that would back up the working_directory as the culprit.

Maybe internally something is going odd and it is taking the '\'s in the working directory string as an escape code or something. I bet if you hard code the working directory path it will work. Doesn't help long term obviously, but would give more information to feed back to YYG.
I thought of this too, but if that were the case then using working_directory to build the source path wouldnā€™t point a valid file as the path would also be being escaped there too.

However I can copy a file FROM the exe folder to elsewhere using working_directory in the source path without an issue, just not TO it using either working_directory to build the destination path or hardcoding the path the folder holding the exe - itā€™s like GMS sees the exe folder as protected / sandboxed no matter how you try to point to it.

@Dan any chance you could quickly check / confirm this and/or take a look at nachoā€™s ticket so we arenā€™t pulling our hair out in confusion please? :)

@nacho_chicken yeah it failed to copy into the folder both running from the IDE in a temp folder and exporting the game and creating an exe for me too.

As I said it doesnā€™t matter whether I use working_directory or hardcore the path to the exe folder on my desktop, nothing ever gets copied into it.
 
Last edited:
H

Homunculus

Guest
Are you guys taking into account working_directory potentially pointing to two different paths depending on the operation you are doing in your test cases?
 

rIKmAN

Member
Are you guys taking into account working_directory potentially pointing to two different paths depending on the operation you are doing in your test cases?
As both me and nacho said above, it doesn't work even if you hardcode the path to the exe folder.
 
H

Homunculus

Guest
I was referring primarily to @Lonewolff tests since he seems to have some kind of success writing outside of the sandbox, except when using working directory
 

rIKmAN

Member
I was referring primarily to @Lonewolff tests since he seems to have some kind of success writing outside of the sandbox, except when using working directory
Yeah that's the issue.
Writing anywhere outside the sandbox works fine, the issue is trying to write to the same directory as the game exe both when using working_directory or hardcoding the path to the exe folder - neither works.

Using working_directory to copy a file FROM the exe directory to anywhere else also works, so the issue seems to be with the exe folder itself remaining sandboxed, rather than working_directory.
 
I think what you will find causing the confusion is that when you perform a read operation using working_directory, it will refer to where the executable is, however, when you do a write operation, working_directory points to %LOCALAPPDATA%/<game name>/

When I run the code
Code:
file_copy("C:\\windows\\system32\\notepad.exe", working_directory + "notepad.exe");
I indeed get a copy of notepad.exe in the following folder:

/Users/<User Name>/AppData/Local/<Game Name>

That's why you can use working_directory to read a file (i.e., copy a file from) from your executable directory, because that's where it points to for reading. But if you try to write a file to working_directory, it pops it into the above mentioned folder.

However! When I use program_directory instead, it has the correct path to the executable folder when I read from, but, when writing to program_directory, it ALSO writes to the /Users/<User Name>/AppData/Local/<Game Name> path.

So I think working_directory is still working as per the manual, but the actual bug lies with program_directory. program_directory seems to be behaving identically to working_directory.

Something weird is going on, but I can copy notepad.exe to my executable folder if I hardcode the path as follows.

I made a build and put it in a manually created folder "c:\test\sandbox"

Code:
show_debug_message(program_directory);
dir2 = program_directory;
// This fully hard-coded line copies notepad.exe to the executable folder successfully :
file_copy("C:\\windows\\system32\\notepad.exe", "c:\\test\\sandbox\\notepad3.exe");
// This line strangely does not, it still goes to %LOCALAPPDATA%
file_copy("C:\\windows\\system32\\notepad.exe", string(dir2) + "notepad4.exe");
program_directory shows up as "c:\test\sandbox"

Even though I tried doubly hard to treat program_directory as a pure string in the second file_copy command, it still sent the file to %LOCALAPPDATA%\<Game Name> . Very weird.

It's as if, when I pass file_copy a purely formatted string as the destination, such as "c:\\test\\sandbox\\notepad3.exe", it will just write it where I tell it to.

But if I pass file_copy a variable as the destination, and that variable happens to contain the path to the executable, it instead writes to %LOCALAPPDATA%
 
Log a ticket with the helpdesk telling them when writing to program_directory it writes to the wrong folder (%appdata%).

In the meantime, based on all of the above, I think you'll have to hard-code the location of your executable directory if you want to write to it.
 
Log a ticket with the helpdesk telling them when writing to program_directory it writes to the wrong folder (%appdata%).

In the meantime, based on all of the above, I think you'll have to hard-code the location of your executable directory if you want to write to it.
I have already logged a ticket. Also, hard-coding the location of the executable directory does not work. Maybe it works if you hardcode the entire filename, but my program is a map editor and user input for filenames is a requirement. I primarily updated the topic with the status of my bug report for @rIKmAN because he asked.
 

rIKmAN

Member
I have already logged a ticket. Also, hard-coding the location of the executable directory does not work. Maybe it works if you hardcode the entire filename, but my program is a map editor and user input for filenames is a requirement. I primarily updated the topic with the status of my bug report for @rIKmAN because he asked.
Any updates yet mate?

If itā€™s been put into Mantis could I have the bug report number or link so that I can keep an eye on it myself and stop bugging you! :)
 
C

Catastrophe

Guest
Yeah we still need this fixed also, eventually, pass it here too xD
 
Any updates yet mate?

If itā€™s been put into Mantis could I have the bug report number or link so that I can keep an eye on it myself and stop bugging you! :)
Still no updates. I haven't gotten another response beyond the one I posted previously.
 

rIKmAN

Member
Still no updates. I haven't gotten another response beyond the one I posted previously.
That's been a month for you now and I've had a ticket which I was recently told wasn't passed on for 2mths so maybe the same thing has happened?

Maybe @Dan could take a look into it if he gets a chance?
 

FrostyCat

Redemption Seeker
I don't understand the zealotry in trying to write to program_directory. Yes, there is a bug right now in the sandbox bypass, and it needs fixing. But even if it's fixed, if your program_directory happens to be protected by UAC virtualization (this notably includes C:\Program Files and C:\Windows and their subdirectories), attempts to write there will be "pretended" away anyways.
 
I don't understand the zealotry in trying to write to program_directory.
It doesn't matter why people are trying to write to program_directory. Functionality is broken and whether or not someone uses said function in a sub-optimal way doesn't affect discussion of the problem.

In my case, my program won't be distributed through an outlet where the default install directory is protected (e.g. Steam). Telling the few people who will have file issues to move the game into a normal directory is significantly easier than telling every single user "go to your local appdata folder by hitting Windows+R then typing '%localappdata%' then find the 'Game' folder and files are stored there." That doesn't even solve any issues since I would still be dealing with people having issues getting to the files even after I've explicitly told them where files are and the exact steps to get to them.
 

rIKmAN

Member
I don't understand the zealotry in trying to write to program_directory.
"Zealotry - fanatical and uncompromising pursuit of...."
Hmm, yeah...calm down Frosty we just want a bug fixed because it doesn't work as it should, we're hardly being fanatical lol...

I'm sure we are all fully aware of UAC limitations, but as nacho said that really has nothing to do with the fact that program_directory is broken.

If a user incorrectly tries to write to a UAC protected directory and has issues then that's their own fault, but it has legitimate and helpful uses for those of us that are aware of the implications if it worked as it should.
 
If it's of any help, I might as well post the ticket number. 162480
Any progress on this? I can't find anything in Mantis for it. Rather than me log another ticket, are you able to respond to your current ticket and ask if this has been logged as a bug or closed if it's not.

I can log a new ticket if you still get nothing.
 
Any progress on this? I can't find anything in Mantis for it. Rather than me log another ticket, are you able to respond to your current ticket and ask if this has been logged as a bug or closed if it's not.

I can log a new ticket if you still get nothing.
To be honest, I have no idea how to do any of that. How would I go about responding to my ticket? I still haven't received an update since the last email on Sept. 22nd.
 

rIKmAN

Member
To be honest, I have no idea how to do any of that. How would I go about responding to my ticket? I still haven't received an update since the last email on Sept. 22nd.
Log in at https://help.yoyogames.com/hc/en-us then click your name in the top right and choose "My Activities" and you'll see a list of all your support tickets.

Open the one related to this issue and you will be able to add a message / extra info to it and it will be reopened if it has been closed for some reason.
 
Top