GMS 2 Unable to write file to program_directory with sandbox disabled

Discussion in 'Programming' started by nacho_chicken, Sep 20, 2019.

  1. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    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?
     
  2. Phil Strahl

    Phil Strahl Member

    Joined:
    Jul 3, 2016
    Posts:
    387
    Does the folder "Maps" already exist inside your program directory?
     
  3. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    Yes. I also tried it without the folder existing and no difference.
     
  4. Yal

    Yal GMC Memer GMC Elder

    Joined:
    Jun 20, 2016
    Posts:
    3,703
    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)
     
  5. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    It does not matter if I use / or \\. I have tested both.
     
  6. TsukaYuriko

    TsukaYuriko Q&A Spawn Camper Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    1,626
    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?
     
  7. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    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: Sep 21, 2019
  8. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    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);
    
     
  9. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
    nacho_chicken likes this.
  10. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    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 likes this.
  11. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    Did you hear anything back regarding this yet?
    I checked Mantis but couldn't see anything related to this on there.
     
  12. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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.
     
  13. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    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?
     
  14. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
  15. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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
     
  16. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    I apologize, I just found the ticket creation confirmation email. That was on Sept. 22nd. Nothing new since then.
     
    rIKmAN likes this.
  17. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
  18. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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 likes this.
  19. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
  20. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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
     
  21. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
    Samuel Venable likes this.
  22. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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.
     
  23. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    It was just a generic "your ticket has been created" email.
    I honestly can't think of anything that needs to be tested further. My own tests were sufficient for me.
     
  24. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    Ah that was to Sam about him saying program_directory returned an incorrect path - I did quote him above my reply.
    The more confirmations the better with the way YYG action bug fixes.
     
    nacho_chicken likes this.
  25. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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.
     
    nacho_chicken and rIKmAN like this.
  26. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
    nacho_chicken likes this.
  27. Lonewolff

    Lonewolff Member

    Joined:
    Jan 8, 2018
    Posts:
    1,207
    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.
     
    rIKmAN and Samuel Venable like this.
  28. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,264
    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: Oct 11, 2019
    rIKmAN likes this.
  29. Lonewolff

    Lonewolff Member

    Joined:
    Jan 8, 2018
    Posts:
    1,207
    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.
     
    rIKmAN likes this.
  30. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    377
    Hard-coding the directory path still fails for me.
     
    rIKmAN likes this.
  31. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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: Oct 11, 2019
  32. Catan

    Catan Member

    Joined:
    Jun 20, 2016
    Posts:
    737
    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?
     
  33. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    As both me and nacho said above, it doesn't work even if you hardcode the path to the exe folder.
     
  34. Catan

    Catan Member

    Joined:
    Jun 20, 2016
    Posts:
    737
    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
     
  35. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,525
    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.
     
    Lonewolff likes this.
  36. IndianaBones

    IndianaBones Member

    Joined:
    Jul 5, 2016
    Posts:
    2,207
    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%
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice