No, DosBox does not provide direct access to the native host file system.

I don't know if newer DosBox versions support this (I did notice that some config commands
are disabled) - but the one I use (formerly MegaBuild-6 with a few extra fixes), if you are not
running in -securemode a program can issue a "mount" command to make a host directory
available as a DosBox drive (and can "unmount" after if you want).

Another thing I've done which is "kinda related" - I have a "WCMD" program in DosBox that
communicates with a Windows side program to issue Windows commands from within DosBox.

--

Also - I don't know if this would interest you or not - I you are looking for a way to write simple
(DOS like) programs that run "as if" they are running on the host (full file system access etc) - and
are willing to write that code within my own "Micro-C" compiler, look at DVM (on my site).

Dvm is a simple 16-bit virtual machine that unlike DosBox has full access to the Host ... I use it *lots*
because I write much of my code in Micro-C and although DVM is not 80x86 (C-FLEA), it has almost
all of the Micro-C/PC (DOS) library built into it (so library calls compile into a single 2-byte instruction).

It lets me take a LOT of the stuff I've written over the years, and just recompile it to get a Windows or
Linux version - It's also small (single 17k EXE), and does not have to be "installed" (just run).

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Thank you for the response. I tried a work-around that I really thought would work. Maybe you can give me some insight. I tried to force the path back up a directory by adding "..\" before the path:
c:\..\XYZ\TEST.TXT (plus many similar variations) . I expected this to translate to:
c:\ABCD\..\XYZ\TEST.TXT
I tried this at a DOS command prompt and it found the file. In the program it still said not found. I should note that files with relative path names are found without a problem.

My software works great in DOSBox. This really is the first quirk I've hit. It is written in Turbo C and I compile it on a Windows 3.1 PC. I would like to get the compiler off of that heavy breathing dinosaur, but that Is a project for another time. I'll take a look at your compiler when I have a chance.

I'm struggling to understand what you're actually trying to do. From your opening post, why not just use "mount c c:\" if you don't want extra path translation steps?

In the documentation (Yes, I actually read it) it strongly advised against using "mount c c:\" for safety reasons.

your problem is that the program expects the path to be C:\ABCD\XYZ\TEST.TXT but as you mounted "MOUNT C C:\ABCD" there is no folder ABCD.
To fix this:
1. create folder in c:\ (on your host) called "DOS"
2. move your folder C:\ABCD into C:\DOS
3. in DOSBox use "MOUNT C C:\DOS"
4. in your program enter the file path C:\ABCD\XYZ\TEST.TXT

Sorry, that's not the issue. There is a folder c:\ABCD. If file TEST.TXT is located in ABCD and I specify: C:\ABCD\TEST.TXT. with MOUNT C C:\ABCD, the file path that is read is:
C:\ABCD\ABCD\TEST.TXT.

This is an overly simplified description to explain the problem. In practice, the software will run on end-user's computers where I don't control the file location or naming.

barryNY wrote on 2025-03-03, 22:42:

In the documentation (Yes, I actually read it) it strongly advised against using "mount c c:\" for safety reasons.

Yes, because it gives the DOS programs access to your entire drive. But that's exactly what you're trying to do anyway, by escaping the sandbox imposed by only being able to access files within C:\ABCD. If your program could do it, so could anything else.

You want the paths inside DOSBox to be exactly the same as they are on the host. That's only possible by mounting the root directory.

barryNY wrote on 2025-03-03, 22:22:

I tried a work-around that I really thought would work. Maybe you can give me some insight. I tried to force the path back up a directory by adding "..\" before the path:

DosBox doesn't pass your whole spec to the system... It kinds looks like it should (because for example, It shows ".." at the
root of a mounted directory - which IMHO it should remove) .. It processes the path, including ".." on it's own, and ignores
any ".." that would take it above it's root.

My software works great in DOSBox. This really is the first quirk I've hit. It is written in Turbo C and I compile it on a Windows 3.1 PC. I would like to get the compiler off of that heavy breathing dinosaur, but that Is a project for another time. I'll take a look at your compiler when I have a chance.

I'm pretty sure I've run Turbo-C (2.0) under DosBox and it mostly works fine.
(IIRC it does sometimes get into a state where it's can't write it's output file after a failed
compiled because Windows things it's still open --- probably however TC is exiting on an error
is't quite handled correctly by DosBox and the file isn't closed -- doesn't happen very often,
and I've never seen it happen with anything else. You don't have to exit DosBox, just open and
close the file)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

barryNY wrote on 2025-03-03, 23:15:

Sorry, that's not the issue. There is a folder c:\ABCD. If file TEST.TXT is located in ABCD and I specify: C:\ABCD\TEST.TXT. with MOUNT C C:\ABCD, the file path that is read is:
C:\ABCD\ABCD\TEST.TXT.

Do you need the program to actually run under DOS?
If you want to access a host file (and since you're writing the program),
you could do something like:

MYopen("path\file"...)

becomes

system("mount T path >NUL)

SYSopen(file)

and MYclose(...)

would become:

close(...)
system("mount -u T")

With appropriate error checking etc.

If you are opening a lot of files, you might make MYopen smart enough to
keep track of subdirectories and only mount new temp drives as
needed (ie: mount the highest directory in the path and open
subparts + filename)

Just some ideas.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

It might be possible to do with softlinks in the host filesystem?

It is ... Not advisable, as it requires creating a "Strange Loop" with regard to the filesystem, but say for instance:

Host: Linux

/home/Someuser/Dosbox/C

This is the path to the C drive.
Inside the ./C folder, there is a symbolic link, linking to /home/Someuser/Dosbox
eg,

ln -s /home/Someuser/Dosbox/C/Dosbox /home/Someuser/Dosbox

Dosbox will treat the symbolic link like a folder, even though it points above the root. This kind of thing is a "Strange Loop"

It is "Not Advisable", because you can have an infinitely recursed path:

C:\Dosbox\C\Dosbox\C\Dosbox\C........

Any kind of program that tries to parse a tree structure, (Like TREE.EXE from DOS) will have a VERY bad day.

Host: Windows

The VERY SAME THING can be done with NTFS using the FSUTIL command to create a hardlink, which will do THE VERY SAME THING... (only caveat, is that a hardlink has to be within the same physical volume, where a linux softlink can POINT ANYWHERE AT ALL)
Microsoft command reference for the needed fsutil invocation

The EXACT SAME PROBLEM with strange loops applies, and is, AGAIN, NOT RECOMMENDED.

This does not PREVENT Dosbox from doing anything, mind-- it just allows you to see above where your C drive was mounted. (By abusing fancy features of the filesystem to do it, and confusing the shit out of both people and software that tries to walk the directory tree.)

It looks like you are just creating a link to the DosBox home directory...?
I had the impression you wanted full access to the entire drive ?
(sorry - just rereading and realized I responded to something not from the original
poster - but the rest of my message may still be useful)

If you don't need access to the whole drive, why not: mount C C:\DosBox
I myself have Y: mounted as the DosBox home directory in all my installs,
(C: happens to be a subdirectory under that)

In either case, a symbolic link doesn't avoid the reason DosBox docs recommend
not to "mount" the whole C: drive ... this is done so that any random programs you
run in DosBox can't corrupt stuff on the rest of your drive. The symbolic link would
give anything that wanted such access - so no extra protection

To be fair, any random program you run natively outside of DosBox has access to
anything your user can access.

If you really do need access to all of C: - mount C C:\
and ignore the warning - nothing gained by making it more complicated.
- and since you're going to be running your own software and/or stuff you
know and trust (I assume only) - malware shouldn't be an issue anyway!

*If you don't want your users to see the warning: mount C C:\ >NUL

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Not exactly dave-- it gives access to the folder just above where the C drive is, not the whole volume.

This is the original question:

Is there a way, within a program running on DOISBox, to prevent a file path from being translated by the mounted directory? […]
Show full quote

Is there a way, within a program running on DOISBox, to prevent a file path from being translated by the mounted directory?

For example, in the DOSBox configuration I have the mount command:
MOUNT C C:\ABCD

In the program running on DOSBox, I enter the file path:
C:\XYZ\TEST.TXT

When the program tries to open the file using C function "OPEN" or "FOPEN", the path it actually tries to open is:
C:\ABCD\XYZ\TEST.TXT

Can a program running on DOSBox prevent this file path name translation?
I have already done extensive searching and experimenting to find a work around and cannot find a solution.

which gives the scenario of the root being

C:\ABCD

in which a directory XYZ is created, with a textfile inside. From Dosbox, this looks like C:\XYZ\TEXTFILE.TXT

But it is really at the path C:\ABCD\XYZ\TEXTFILE.TXT

In the case I outlined, there is a symlink. To match their example, it would be named ABCD. it would be in C:\ABCD

So, C:\ABCD\ABCD points to C:\ABCD

From within Dosbox, this would look like C:\ABCD and would just list the same content as the C drive does. (you could CD into an infinite number of ABCD subfolders, due to the strange loop) Their path, with C:\XYZ, would thus also have the traversable path C:\ABCD\XYZ, exactly as their example.

It would not need to see the whole host C drive. The symlink would make a special condition where that one path is superficially the same, via trickery.

wierd_w wrote on 2025-03-04, 06:28:

Not exactly dave-- it gives access to the folder just above where the C drive is, not the whole volume.

Fair enough - things like this are exactly why I always give full paths to mount (Esp. in config)

You can then capture the output of "mount" to see where exactly each drive references,
then it you want you can remove subdirectories from the end of that
string and mount a temp drive to access it...

But in this case, why not just mount the drive one level higher...
I *think* the reference to "one level higher" was an example to show the
problem ... if they truly want access to the whole drive, then they
will have to mount the whole drive!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal