VOGONS


First post, by rico001

User metadata
Rank Newbie
Rank
Newbie

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

Reply 1 of 4, by Rekrul

User metadata
Rank Member
Rank
Member
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?

Reply 2 of 4, by DaveDDS

User metadata
Rank Oldbie
Rank
Oldbie

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)

https://dunfield.themindfactory.com ; "Daves Old Computers" ; SW dev addict best known:
ImageDisk: rd/wr ANY floppy PChw can ; Micro-C: compiler for DOS+ManySmallCPU ; DDLINK: simple/small filetransfer(w/o netSW)via Lan/Lpt/Com

Reply 3 of 4, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 4 of 4, by DaveDDS

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on Today, 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

https://dunfield.themindfactory.com ; "Daves Old Computers" ; SW dev addict best known:
ImageDisk: rd/wr ANY floppy PChw can ; Micro-C: compiler for DOS+ManySmallCPU ; DDLINK: simple/small filetransfer(w/o netSW)via Lan/Lpt/Com