Windows Does a GMS game share Windows OS USB automatic mounting device detect feature?

Im not sure about this, but does a GMS game share Windows's USB automatic mounting detection feature, where if I plug in a USB flash drive ( or USB hard drive ) into a USB port, the Windows OS detects the USB device and shares this information with the GMS game, which then the GMS game validates the existence of the USB flash drive that I can access in my game by a device specified file path to the root directory?

OR...

.....do I have to design a manual mounting feature for a GMS game, so that the game is told that there is a USB flash drive attached, and a device specified file path for a USB flash drive that it can access, which has already been plugged into a USB port? Again, the file path would be the root directory of the USB flash drive, that has to be typed in by the player.

Thanks
 

rIKmAN

Member
If Windows can mount the drive and assign it a drive letter, then GM can access it like it would any other drive when the sandbox is turned off and there are no other OS level permissions / restrictions in place (local or network) that would prevent access.

Quick way to test is to create a text file with a single line of text in it on the root of the USB, then in GM make sure the sandbox is off, then open the file and read the string.

EDIT:
Did a quick test and as expected it works fine.
 
Last edited:

GMWolf

aka fel666
When you open a file, that's a sys call. You give the os a path and ask it to return a file handle.
Your game executable never needs to know about the file system, what drives are mounted etc. It just gives a path to the OS and it handles the rest.

Unless, you were asking about detecting when a USB drive is plugged in and triggering an event?
 

Coded Games

Member
Which you could make an event that triggers when a usb drive is plugged in. To check if a drive letter exists just attempt to write a file to the root of the letter. If you get an exception or error then the drive doesn’t exist. Remember all the drives that exist on start up. Now repeat that process every few steps, maybe once a second or something, and see if any new drive letters show up. There is your USB drive event.
 
If Windows can mount the drive and assign it a drive letter, then GM can access it like it would any other drive when the sandbox is turned off and there are no other OS level permissions / restrictions in place (local or network) that would prevent access.

Quick way to test is to create a text file with a single line of text in it on the root of the USB, then in GM make sure the sandbox is off, then open the file and read the string.

EDIT:
Did a quick test and as expected it works fine.
So this can only work if the sandbox is turned off in the windows game options, otherwise if the sandbox is enabled it is blind to the other devices because it can not go outside of the game's directory that is created.... right?
 

rIKmAN

Member
So this can only work if the sandbox is turned off in the windows game options, otherwise if the sandbox is enabled it is blind to the other devices because it can not go outside of the game's directory that is created.... right?
It can not go outside of the sandbox, which is not the same as the "games directory" - read more info on the sandbox here.

Even with the sandbox off you would also still be bound by any OS level and/or UAC permissions locally on the machine, as well as any network assigned permissions if the machine was part of a managed network that required users to logon (ie. school/uni/work/library etc). If that account wasn't granted permission to use USB devices then the access request would be denied.

It's unlikely that places like that would prevent access to reading/writing from a USB drive though as students/employees bring in files to print, transfer etc as part of regular use.
They more usually lock down the ability to install/uninstall software, run unknown executables/scripts and such, but it's something to be aware of.
 
Last edited:
It can not go outside of the sandbox, which is not the same as the "games directory" - read more info on the sandbox here.

Even with the sandbox off you would also still be bound by any OS level and/or UAC permissions locally on the machine, as well as any network assigned permissions if the machine was part of a managed network that required users to logon (ie. school/uni/work/library etc). If that account wasn't granted permission to use USB devices then the access request would be denied.

It's unlikely that places like that would prevent access to reading/writing from a USB drive though as students/employees bring in files to print, transfer etc as part of regular use.
They more usually lock down the ability to install/uninstall software, run unknown executables/scripts and such, but it's something to be aware of.
I am only dealing with the save area, in terms of files that I need to write, read, and change that have nothing to do with the file bundle of the actual game.

What I want to do is design my game so that the user can put the game installation on the local C: drive, but also have the ability for game save files and map data to be written to a external USB flash drive so that the user does not need to consume the available space of the local C: drive. The save area of my game needs to know what device I am using as a specified file path, if its not by default the local C: drive with where ever the current working directory is at the time. In other words, my game will operate from the file bundle from the local C: drive, but also have the option for the user, to save files to a specified path on the USB flash drive as well. The game switches where the current working
directory is , using file paths in the operation.
 
The question I have been trying to find the answer is , for the Windows OS, what is the depth limit ( if such exists ) of a sub-directory chain starting from the the root directory? In other words, how many times can you make a new sub-directory in a recently created sub directory, and repeat the processs, until Windows complains that it cant handle that depth according to its limits.
 
Until you reach the max length of a path. Since the length of a path depends on the length of the directory names, there's no one specific limit on the number of directories.
Read https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd for ways to get around the historically short 260 character limit.
Well my solution would be, use more than one path. Go to the sub-directory with one path, and then when your at that sub-directory, use another path to go the intended location.
 

chamaeleon

Member
Well my solution would be, use more than one path. Go to the sub-directory with one path, and then when your at that sub-directory, use another path to go the intended location.
Why wouldn't you explore the possibility of using UNC paths first?

Edited to remove undesired code.
 
Last edited:

GMWolf

aka fel666
I don't understand your problem.
The user is already specifying the path, presumably including the root drive.

So what's the issue here?
Just use that path to construct your sub path and save/lload your files .
You don't need to mount and file systems. That's what operating systems are for.
In general you can't exceed the max path length (260) so just avoid those.
 
Why wouldn't you explore the possibility of using UNC paths first?
Because I am used to using traditional MS-DOS paths, in addition to that I am only accessing a external drive such as a USB storage device, on a single computer, not a network. Also, UNC paths do not allow device letters in their paths. I have to have a distinction between the
local device and the external USB storage device.

See File path formats on Windows systems
 

chamaeleon

Member
Because I am used to using traditional MS-DOS paths, in addition to that I am only accessing a external drive such as a USB storage device, on a single computer, not a network. Also, UNC paths do not allow device letters in their paths. I have to have a distinction between the
local device and the external USB storage device.

See File path formats on Windows systems
UNC paths does not require using a network. My example uses C: in the path if you look a bit more carefully. I could have used a couple of my USB drives with their respective drive letters if I wanted to. In effect, the only difference between a path you want to use and the path I created is that mine starts off with \\?\ before the drive letter.
 
So what's the issue here?
Just use that path to construct your sub path and save/lload your files .
You don't need to mount and file systems. That's what operating systems are for.
In general you can't exceed the max path length (260) so just avoid those.
The problem is that I did not know if GMS recognizes USB devices when Windows OS automatically recognizes them when they are plugged in. There is no documentation for GMS, that I have read, that states if GMS knows this or not from the Windows OS. I am not expecting the documentation for GMS to have it anyways. However, I cant make that assumption that what I want to do is possible, because of the sandbox. So I anticipated the problem with the fall back idea of creating a manual method of telling GMS that the USB storage device has been mounted and that it exists. Then in my program, I would provide the means for the user to specify a file path for that USB storage device. Now I know that I dont need to use that fall back idea.
 
UNC paths does not require using a network. My example uses C: in the path if you look a bit more carefully. I could have used a couple of my USB drives with their respective drive letters if I wanted to. In effect, the only difference between a path you want to use and the path I created is that mine starts off with \\?\ before the drive letter.
Have you seen that link that I provided, it clearly states on that MS website page :

UNC paths

Universal naming convention (UNC) paths, which are used to access network resources, have the following format:
  • A server or host name, which is prefaced by \\. The server name can be a NetBIOS machine name or an IP/FQDN address (IPv4 as well as v6 are supported).
  • A share name, which is separated from the host name by \. Together, the server and share name make up the volume.
  • A directory name. The directory separator character separates subdirectories within the nested directory hierarchy.
  • An optional filename. The directory separator character separates the file path and the filename.
Nowhere does it mention the use of device letters - and its application is designed for networks.
 

rIKmAN

Member
Im going to try that idea..... thanks for the help, btw.
It works, I tested it reading from/writing to a text file on both on the root and inside a directory created in code on the USB drive earlier today when I first replied to you.
Just remember to turn off the sandbox.
 
Last edited:

chamaeleon

Member
@chamaeleon

That is a DOS device path, not a UNC path.
Fine. It is a dos device path. I don't really care. It has been a very long time (a decade or two) since I read the actually documentation on them, and in my mind the prefix used just made it a unc path. That they also split that up into two categories to distinguish between a network resource and a local resource, I don't care at all about. I would care of I needed to write a server name instead of the question mark, etc. But not what the path is called in their documentation, only what it needs to contain.

I was just trying to show a way for you to avoid going down the insane route of having to implement a windows extension so you can call chdir() so you in turn can use string functions to split up a full path into several segments so you can change current directory, in an attempt to overcome the path length limit when writing or reading a file. It seems like prepending the four characters to the filename offers a, well, easier way. But do go ahead and do it if you want to, it doesn't hurt to try new things.
 

GMWolf

aka fel666
I still don't understand. Or rather, i think you may be confused as to what it is you are trying to do. (or worst, (but ill give you the benefit of the doubt), you are more concerned about seeming knowledgeable than asking any real questions):

You mention mounting drives a few times.
Mounting refers to making the drive accessible through the filesystem. The OS takes care of this.
You *could* write an application that does not make use of the filesystem and writes to the drive directly. You would need to to implement the file system driver, but its feasible. However I strongly doubt that is what you are trying to do.
Either way, you shouldnt' need to mount the drive yourself. Windows will mount the drive automatically, and made accessible through the file system.


If you read about "the file system" in the GMS manual, you will find a section that describes how the sandbox limits read and write operations:
Reading is limited to the working directory and the save area.
Writing is limited to the save area.

However you can bypass the sandbox with get_open_filename and get_save_filename which will prompt the used to select a path. those files will then be made read/writable by GMS.

The question I have been trying to find the answer is , for the Windows OS, what is the depth limit ( if such exists ) of a sub-directory chain starting from the the root directory? In other words, how many times can you make a new sub-directory in a recently created sub directory, and repeat the processs, until Windows complains that it cant handle that depth according to its limits.
thats an entirely separate issue. Huge pain. my advice: don't rely on long paths. Let the user realize windows is a steaming pile of crap and in 25 years maybe microsoft will fix it.

but to me this is routine.
I retract the nested parentheses at the top of my post.
 

Coded Games

Member
Let the user realize windows is a steaming pile of crap
Yes! The problem would be incredibly easy on MacOS/Linux. Path limit is 4096 characters. If you want to see all the mounted drives just look at what folders are in /Volumes or /media. No stupid drive letter garbage.
 
I still don't understand. Or rather, i think you may be confused as to what it is you are trying to do. (or worst, (but ill give you the benefit of the doubt), you are more concerned about seeming knowledgeable than asking any real questions):

You mention mounting drives a few times.
Mounting refers to making the drive accessible through the filesystem. The OS takes care of this.
You *could* write an application that does not make use of the filesystem and writes to the drive directly. You would need to to implement the file system driver, but its feasible. However I strongly doubt that is what you are trying to do.
Either way, you shouldnt' need to mount the drive yourself. Windows will mount the drive automatically, and made accessible through the file system.

If you read about "the file system" in the GMS manual, you will find a section that describes how the sandbox limits read and write operations:
Reading is limited to the working directory and the save area.
Writing is limited to the save area.

However you can bypass the sandbox with get_open_filename and get_save_filename which will prompt the used to select a path. those files will then be made read/writable by GMS.
Im going to explain what I was thinking that made me post this question in this forum.

I want to program an option that will allow the user to save storage space on their local hard drive, by allowing the use of a external device such as a USB flash drive or USB hard drive. That way the user can save their save postions in my game ( which is complex of games ) and the data that the game produces that is written to the game directories. When someone plugs a USB device into a USB port of a Windows PC, the Windows OS detects this and mounts the device to the tree of devices that I see when I open a directory window. To all the other programs running on the machine, can see this and when you use their open file option , you can connect to the USB flash drive to access the files. To sum it up, thats what I call the mounting process, when a USB flash drive is mounted automatically by Windows.

Now lets look at GMS. According to the manual, the game segregates the game from the rest of the windows OS system of the device ( the local hard drive of where game would be installed or where GMS places the game during its development ) in what GMS refers as the sandbox. What I did not know is if the sandbox wouldn't let me access a external USB flash drive even though it is mounted by Windows, because GMS might not know its there.

I was thinking of the GMS sandbox of being similar to operating like the Linux OS. In Red Hat 9, you use the "mount" command in order for the USB flash drive to be recognized. When I was using gcc in Red Hat 9, I had to use the Linux command "mount" everytime I plugged in a USB flash drive and use the "unmount" command to tell the OS, when I am going to unplug the USB flash drive. Thats where I came up the alternative idea, "...oh man, Im going to have to invent something like Linux "mount" and "unmount" commands as two functions in GMS, for Windows ! ".

GMS does not work like that. Now, I know that I dont have to invent such commands in GMS ( and I really dont want to ).

The problem is not in the programming, the problem which I was not sure of, is how GMS works with windows OS in this matter.
Since I did not know ( as I stated in my post ) is the reason why I posted the question.

thats an entirely separate issue. Huge pain. my advice: don't rely on long paths. Let the user realize windows is a steaming pile of crap and in 25 years maybe microsoft will fix it.
In regarding the file path problem, I came to the same conclusion you have stated. The key word you state, "MAYBE" microsoft will fix it, or not , is how I view Microsoft's management of their products. But the solution to that problem , might be easier said than done.

So you're right in saying that.
 
Last edited:
Top