rico001 wrote on 2026-07-08, 19:50:

Is there a better way to explain: […]
Show full quote

Is there a better way to explain:

Example:
Z:>mount d c:\images
Z:>d:
D:>imgmount c "70mb.img"

(from wiki 26 october 10 https://www.dosbox.com/wiki/IMGMOUNT)

I get errors like : the image must be on a host or local drive

What does IMGMOUNT do differently in memory? vs a mounting a drive letter? Not really wanting help with a problem, but a better explanation, if possible ...

Suggestion : Maybe tell the user to mount the image in a local drive path -- The Specified drive letter must be mounted to access the image file ... Related Curiosity? --How is this specified by physical hardware

I'm not an expert in this area, but since nobody else has answered this, I'm going to post my theory...

I think that the problem is that the MOUNT and IMGMOUNT commands are "outside" of the DOS environment. They work with real directories to set the emulated directories for DOS to use. So while DOS thinks it's in the D: drive, the IMGMOUNT command is still in whatever the real current directory is.

Kind of like how if you run an emulator and you configure a real controller, the emulator itself is completely oblivious to any control changes a game might let you make. A game might let you remap the buttons, but when you go back to the emulator's configuration, it will still be the same, because the configuration sits outside the emulated system.

Does that make sense?

I've not looked into this in detail, but "mount"ing an local directory-tree is a completely different function that "imgmount"ing an actual drive image.

When you "mount" a directory tree, DosBox has to track the part and convert local file operations into host file operations. It doesn't see the actual storage of the filesystem.

Imgmount on the other hand just provides BIOS access to sectors within the image. This is just a binary file to the host which knows nothing about files within it!
The actual FAT implementation of the file system has to be done within DosBox (which sometimes has problems - I've had file operations fail on IMGMOUNTed drives - this is the main reason I created my "FDI" (FloppyDiskImage) tool to create and manipulate floppy disks images and files within them directly)

One place you can see this is "SUBST" on a local MOUNTed drive, SUBST just creates a new mount to a different point on the original MOUNT path.
... but ... SUBST doesn't work on an IMGMOUNTed drive - it doesn't have to smarts to redirect an access point to a new directory junction.

One place I effectively use IMGMOUNTed drives a lot is by BOOTing a floppy drive image.
DOSBOX BIOS correctly provides access to 512 byte (sector sized) "chunks" in that image, and a BOOTed DOS will run and access it's file system as normal (in this case the FAT implementation is being done by the booted DOS)

I have no idea why IMGMOUNT couldn't work on on a image mounted over the network. You can still read/write/seek in such an image, which is all you would need to access virtual sectors (a bit slower perhaps - but it should still work)

It's because you're using quotes to access a file on a mounted drive. You can't do that - either use quotes to specify the full path name on the host ("c:\images\70mb.img"), or use the filename that "dir" shows with no quotes.

jmarsh wrote on Yesterday, 02:45:

It's because you're using quotes to access a file on a mounted drive. You can't do that - either use quotes to specify the full path name on the host ("c:\images\70mb.img"), or use the filename that "dir" shows with no quotes.

I don't think that's it....

Like "mount", "imgmount" is referencing files/locations directly on the host which may have spaces in the names, so quotes make sense.

I have no problem mounting an image with the name in quotes: (in this case R:\A.IMG is a floppy disk image on my RamDisk)

C:\> imdmount A "R:\A.IMG"
Drive A is mounted as R:\A.IMG

- It behaves the same without quotes (so I don't think there's any other special significance to the quites other than allowing spaces)
C:\> imgmount A R:\A.IMG

It's worth noting that SUBST shows a similar "Local drives only" error (with no quotes in the names) when applied to an IMGMOUNTed drive.

C:\> SUBST B: A:\XXX
SUBST failed. You either ,ade an error in your command limeor the target drive is already used.
It's only possible to use SUBST on Local drives

DaveDDS wrote on Yesterday, 04:01:

I don't think that's it.... […]
Show full quote

I don't think that's it....

Like "mount", "imgmount" is referencing files/locations directly on the host which may have spaces in the names, so quotes make sense.

I have no problem mounting an image with the name in quotes: (in this case R:\A.IMG is a floppy disk image on my RamDisk)

C:\> imdmount A "R:\A.IMG"
Drive A is mounted as R:\A.IMG

- It behaves the same without quotes (so I don't think there's any other special significance to the quites other than allowing spaces)
C:\> imgmount A R:\A.IMG

It's worth noting that SUBST shows a similar "Local drives only" error (with no quotes in the names) when applied to an IMGMOUNTed drive.

C:\> SUBST B: A:\XXX
SUBST failed. You either ,ade an error in your command limeor the target drive is already used.
It's only possible to use SUBST on Local drives

Look again. You are quoting a full/entire pathname. OP is attempting to quote only a filename, which doesn't work for accessing files on a mounted drive because the translation layer doesn't handle quotes.
SUBST has nothing to do with this, IMGMOUNT is an internal DOSBox program.

jmarsh wrote on Yesterday, 11:42:

Look again. You are quoting a full/entire pathname. OP is attempting to quote only a filename, which doesn't work for accessing files on a mounted drive because the translation layer doesn't handle quotes.
SUBST has nothing to do with this, IMGMOUNT is an internal DOSBox program.

I actually "got" that, what which is why I also said:

- It behaves the same without quotes (so I don't think there's any other special significance to the quites other than allowing spaces)
C:\> imgmount A R:\A.IMG

---
Worth noting: Directory/File names shown in the following text do NOT contain spaces, the commands shown work both WITH and WITHOUT quotes (I just didn't feel the need to quote everything twice)
---

I think IMGMOUNT handles quotes just fine (and I don't think it's going through a "translation layer"). If I place A.IMG in the DosBox home directory,

1C:\> imgmount A "a.img"
2Drive A is mounted as A.IMG

Works just fine!

but .. worth noting: If I switch to my R: drive first:

1C:\> R:
2R:\> imgmount A "a.img"
3Drive A is mounted as A.IMG

It also works even though A.IMG is NOT on my R: RamDrive now!

The reason is that imgmount is accessing host files directly, not through DosBox directory translation, and with no path it's referencing the DosBox home directory (where DosBox.EXE was started from)

--

Last time I looked SUBST is also a DosBox internal command, I have no SUBST.EXE or SUBST.COM anywhere in my mounted drives or PATH:

1C:\> subst
2SUBST failed. You either made an error in your commandline or the target drive is already used.
3It's only possible to use SUBST on Local drives
4C:\>

The reason I mentioned it is that it is also dealing with "mounting" drives (If you perform a SUBST - DosBox SUBST can't show or unSUBST SUBSTed drives, but MOUNT will show the SUBSTed directory as mounted on the SUBST drive, and MOUNT -U works to remove it), and as seen in the error message above it mentioned that you can only use it on "Local drives" (which was part of the original question)

1R:\>subst D: R:\
2Drive D is mounted as local directory R:\
3R:\>mount
4Current mounted drives are:
5Drive C is mounted as local directory C:\DosBox\C\
6Drive D is mounted as local directory R:\
7Drive R is mounted as local directory R:\
8Drive Y is mounted as local directory C:\DosBox\
9Drive Z is mounted as Internal Virtual Drive
10R:\>mount -u D:
11Drive D has successfully been removed.
12R:\>

Looking back at the original post:

rico001 wrote on 2026-07-08, 19:50:

Example: Z:>mount d c:\images Z:>d: D:>imgmount c "70mb.img" […]
Show full quote

Example:
Z:>mount d c:\images
Z:>d:
D:>imgmount c "70mb.img"

After writing my last response, I think the answer is fairly obvious.

It has nothing to do with quotes - what it does have to do with is that IMGMOUNT is referencing a HOST file, and without a PATH in the filename, it will assume it is located in the HOST current directory(where DosBox was launched)

For MOUNTing directories relative to previously MOUNTed "drives", DosBox provides the SUBST command.
but ... AFAIK there is no equivalent function for IMGMOUNTing relative - so you will have to supply the complete
HOST path (or put 70mb.img" in the DosBox home directory)

And ... if that full host path contains spaces - you will need quotes!

DaveDDS wrote on Yesterday, 12:57:

I actually "got" that, what which is why I also said: […]
Show full quote

I actually "got" that, what which is why I also said:

- It behaves the same without quotes (so I don't think there's any other special significance to the quites other than allowing spaces)
C:\> imgmount A R:\A.IMG

---
Worth noting: Directory/File names shown in the following text do NOT contain spaces, the commands shown work both WITH and WITHOUT quotes (I just didn't feel the need to quote everything twice)
---

I think IMGMOUNT handles quotes just fine (and I don't think it's going through a "translation layer"). If I place A.IMG in the DosBox home directory,

Copy code to clipboard

1C:\> imgmount A "a.img"
2Drive A is mounted as A.IMG

Works just fine!

but .. worth noting: If I switch to my R: drive first:

Copy code to clipboard

1C:\> R:
2R:\> imgmount A "a.img"
3Drive A is mounted as A.IMG

It also works even though A.IMG is NOT on my R: RamDrive now!

Yes, and that's exactly why it's failing for OP: they're quoting a relative path but the file is NOT in the DOSBox home directory - it's in c:\images, mounted as d, which is the one case you didn't test yet. DOSBox attempts to find the fully quoted filename on the mounted D drive (which is actually c:\images), it fails because the translation layer can't find it (DOSBox uses the translation layer for all mounted filesystems to map long/invalid filenames to 8.3), then it looks for 70MB.img in the DOSBox home directory and that doesn't exist either. So it shows the error message. IMGMOUNT works perfectly fine to load files from mounted drives provided the translated filename is used - the quotes screw that up.

Is this clear now? A quoted path should refer to a location on the host machine, not a mounted drive because the translation layer can only understand the 8.3 filenames that it provides. If you want to ensure the IMGMOUNT command will work when specifying a file on a mounted drive, use DIR first to see what the translated filename is and specify it without quotes.

This isn't conjecture, it's easily verifiable by building DOSBox and following the control flow yourself with a debugger. So please stop arguing with me about it. And please stop mentioning SUBST - it has nothing to do with loading an image file, which is the root cause of the problem.

jmarsh wrote on Yesterday, 13:38:

Is this clear now? A quoted path should refer to a location on the host machine, not a mounted drive because the translation layer can only understand the 8.3 filenames that it provides. If you want to ensure the IMGMOUNT command will work when specifying a file on a mounted drive, use DIR first to see what the translated filename is and specify it without quotes.

This isn't conjecture, it's easily verifiable by building DOSBox and following the control flow yourself with a debugger. So please stop arguing with me about it. And please stop mentioning SUBST - it has nothing to do with loading an image file, which is the root cause of the problem.

Sorry, no - not clear - this is what I personally "verified":

My DosBox is located in C:\DosBox
among other things, the AUTOEXEC section of DOSBOX.INI (dosbox.conf for most others) contains:

1mount C C:\DosBox\C
2mount R R:\

There is a file "C:\DosBox\WorkingDOS.IMG" which contains a bootable DOS floppy image.

So, please explain how the lack of quotes is affecting this sequence of commands:

1[just launched DosBox]
2C:\> r:
3R:\> dir
4Directory of R:\.
5$RECYCLE BIN   <DIR>            05-09-2026  6:39
6    0 File(s)                 0 Bytes.
7    1 Dir(s)        262,111,744 Bytes free.
8R:\>imgmount a workingdos.img
9Drive A is mounted as workingdos.img
10R:\>mount -u a
11Drive A has successfully been removed.
12R:\>imgmount A workin~1.img
13Drive A is mounted as workin~1.img
14R:\> mount Y C:\DosBox
15R::\> dir Y:\
16Directory of Y:\.
17.              <DIR>            05-09-2026 10:51
18..             <DIR>            01-01-1980  0:00
19   {extra entries removed}
20WORKIN~1 IMG          1,474,560 16-07-2026 18:36
21   {extra entries removed}
22  122 File(s)        16,118,011 Bytes.
23   14 Dir(s)        262,111,744 Bytes free
24R:\>

Seems like the operand to IMGMOUNT can be either the host filename or the DosBox translated name, in both cases assuming the DosBox home directory if the name does not contain a path, and again - like most command line operands on most hosts (in this case Winblows) - quotes are only significant as a means of parsing command line operands which may contain spaces.

Please explain how this is incorrect.

DaveDDS wrote on Yesterday, 15:23:

Please explain how this is incorrect.

You've just done a bunch of tests using unquoted filenames to mount files from host drives, to try and prove that quoted filenames work with mounted drives.

Are you really this dense? The code is available, you can go and look at it, but you'd rather argue that your gut feeling knows better?

Sorry, being "dense" I though this statement:

DaveDDS wrote on Yesterday, 04:01:

- It behaves the same without quotes (so I don't think there's any other special significance to the quotes other than allowing spaces)

Would indicate that quotes make no difference - which was at odds with your statements:

jmarsh wrote on Yesterday, 02:45:

It's because you're using quotes to access a file on a mounted drive. You can't do that - either use quotes to specify the full path name on the host ("c:\images\70mb.img"), or use the filename that "dir" shows with no quotes.

jmarsh wrote on Yesterday, 13:38:

... A quoted path should refer to a location on the host machine, not a mounted drive ...

And ... I foolishly assumed I didn't need to show all the tests with and without quotes.

But, just to insure my mumbling is clear to your "less dense" intellect:

This is what's actually in my DosBox home directory (where it launches)

1 Directory of C:\DosBox
22026-07-16  06:36 PM         1,474,560 WORKIN~2.IMG WorkingDOS.IMG
3               1 File(s)    1,474,560 bytes

These are the directories mounted in DosBox:

1Current mounted drives are:
2Drive C is mounted as local directory C:\DosBox\C\
3Drive R is mounted as local directory R:\
4Drive Y is mounted as local directory C:\DosBox\
5Drive Z is mounted as Internal Virtual Drive

And here are the test commands I actually performed:

1R:\>xdir/cu Y:\*.IMG
226-07-16  6:36p    1,474,560 Y:\WORKIN~1.IMG
3R:\>xdir/cu *.IMG
426-09-05  4:47p    1,474,560 R:\A.IMG
5R:\>imgmount A WorkingDOS.IMG
6Drive A is mounted as WorkingDOS.IMG
7R:\>mount -u A:
8Drive A has successfully been removed.
9R:\>imgmount A Workin~1.IMG
10Image file not found.
11R:\>imgmount A Workin~2.IMG
12Drive A is mounted as Workin~2.IMG
13R:\>mount -u A:
14Drive A has successfully been removed.
15R:\>imgmount A "WorkingDOS.IMG"
16Drive A is mounted as WorkingDOS.IMG
17R:\>mount -u A:
18Drive A has successfully been removed.
19R:\>imgmount A "Workin~1.IMG"
20Image file not found.
21R:\>imgmount A "Workin~2.IMG"
22Drive A is mounted as Workin~2.IMG
23R:\>mount -u A:
24Drive A has successfully been removed.

Sorry, but being so dense ... I can't tell the difference between what must obviously be very different outputs from IMGMOUNT applied to different (and non-existant) files!

And just an extra note - Clearly: IMGMOUNT is not using any "DosBox Translation Layer" because DosBox shows the "short" name of "WorkingDOS.IMG" as "WORKIN~1.IMG" and Winblows short name is "WORKIN~2.IMG" (yes, I went out of my way to make this the case) - yet:

1IMGMOUNT ["]Workin~1.IMG["] fails! (the DosBox translated name)
2IMGMOUNT ["]Workin~2.IMG["] works! (Winblows native short filename)

--- No need to reply - I see no advantage to continuing this conversatioin ---

Have a nice day, enjoy knowing for certain that "A quoted path should refer to a location on the host machine, not a mounted drive"

---

And for the record I've looked at the DosBox sources - I can't say I enjoy going through them much, it mostly seems not coded in ways I would have done differently. I've not counted how much source there is, but given that the 7 essential files of the edition I use total 2,279,551 bytes - I can tell you it's a LOT - more than I care to know in detail (I've looked just enough to find/fix some annoying bugs).

Contrast this with my own DVM.EXE (Dunfield Virtual Machine) which is a single 15,392 byte .EXE that needs no libraries or supporting files.
(Yeah, both are compressed executables - so real code is bigger - but 150x seems excessive no matter how much more it does)

It's obviously not the same, DVM doesn't emulate hardware, and implements "C-FLEA": a processor I designed years ago to be a fairly optimal target for my compiler... but it does implement enough of DOS that I can take most of the stuff I've written for DOS in the last 25+ years and simply recompile it to a .DVM executable which I can run under Winblows just fine!

Again you're testing the wrong thing.... not a single test shows using a quoted filename to mount an image from a mounted drive. Every one of your tests involves mounting a file directly from the host so the translation layer isn't used.

jmarsh wrote on Yesterday, 22:09:

Again you're testing the wrong thing.... not a single test shows using a quoted filename to mount an image from a mounted drive. Every one of your tests involves mounting a file directly from the host so the translation layer isn't used.

As I had suggested earlier, it appears to allow either host path or DosBox translated path irrespective of quotes.
There is no T: drive on my system and "a.img" is not within the DosBox home directory:

1Drive T is mounted as local directory C:\Temp\
2C:\>xdir/cu T:\*.img
326-09-05  7:11p    1,474,560 T:\A.IMG

This is via the native host path:

1R:\>imgmount A C:\temp\a.img
2Drive A is mounted as C:\temp\a.img
3R:\>mount -u a
4Drive A has successfully been removed.
5R:\>imgmount A "C:\temp\a.img"
6Drive A is mounted as C:\temp\a.img
7R:\>mount -u A
8Drive A has successfully been removed.

This is via the DosBox translation:

1T:\>imgmount A a.img
2Drive A is mounted as C:\Temp\A.IMG
3T:\>mount -u a
4Drive A has successfully been removed.
5T:\>imgmount A "a.img"
6Drive A is mounted as C:\Temp\A.IMG
7T:\>mount -u A
8Drive A has successfully been removed.
9T:\>R:
10R:\>imgmount A T:\a.img
11Drive A is mounted as C:\Temp\A.IMG
12R:\>mount -u a
13Drive A has successfully been removed.
14R:\>imgmount A "T:\a.img"
15Drive A is mounted as C:\Temp\A.IMG
16R:\>mount -u a:
17Drive A has successfully been removed.

I still don't see that the presence of quotes is having any effect on the operation of IMGMOUNT (which you had indicated is a significant factor, and is what I've seem to be so "dense" about - see last message).

*1: If quotes really DO indicate a host path, then IMGMOUNT A "T:\A.IMG"
should NOT have worked. This path does NOT exist on the host.

so... What exact test would be "correct" to confirm your conjecture?

I find that fact that it can use either host or DosBox paths a bit ackward - leading to an unknown result if you happen to have something like:

1C:\img\A.IMG
2C:\DosBox\C\img\A.IMG
3---
4mount C C:\DosBox\C
5imgmount A C:\img\A.IMG

If it tries host path first, it will mount C:\img\A.IMG
if if tries DosBox path first: C:\DosBox\C\img\A.IMG

The DosBox document does say "The location can be on a mounted drive inside DOSBox, or on your real disk." but I don't see a clear statement about how this type of conflict would be resolved.

Yes, I know - Why would you document that when any user can simply comb through many thousands of lines of source code to see how it's done!

I suppose I could test this by placing a different A.IMG in the two locations mentioned above, but why bother with all that work. I do still think your response to the OP that his problem was because of quotes is incorrect (see *1 above) but clearly one of us may in fact be "dense" 😀 and I doubt we can reach any definitive conclusion!

I thought there was "no advantage to continuing this conversatioin" so I wasn't going to mention it but you're obviously not using regular DOSBox, otherwise it would be complaining about a missing -size parameter; you can't imgmount floppy images without specifying -t floppy.