Mounted host file access overflows above 2 GiB on Windows (official 2025.12.01 VS SDL1 64-bit build)

[Andresmaga]

Describe the bug

On Windows x64, DOSBox-X fails when a DOS application accesses a mounted host file slightly above 2 GiB.

In my case this happens with RM/COBOL-85 Runtime for DOS and a large data file mounted from a Windows host directory. The same DOS runtime, program, and data work correctly in a 32-bit Windows environment, but fail inside DOSBox-X when the file is accessed from a mounted host drive.

The DOS application aborts with:

COBOL I/O error 30,131 on FAC-FILE file F:\VENTAS\LOC-FACT.DAT.
COBOL I/O error at line 2758 in NE253 (F:\VENTAS\NE253.COB) compiled 26/04/07
10:45:53.

The file size is 2149580800 bytes, which is slightly above 2147483647, so this appears consistent with a signed 32-bit file positioning overflow in the mounted local drive path.

Steps to reproduce the behaviour

1. On Windows x64, mount a host directory as a DOS drive in DOSBox-X.
2. Run a DOS application that opens a large file from that mounted host directory.
3. In my case:
   • DOS runtime: M/COBOL-85 Runtime - Version 5.01.01 for DOS 2.00+
   • Program: NE253.COB
   • File opened: F:\VENTAS\LOC-FACT.DAT
   • File size: 2149580800 bytes
4. Use DOSBox-X with a mounted host directory and reproduce the file access.
5. The program aborts with the above I/O error.

Expected behavior

The file should be accessed normally, the same way it is with the same DOS runtime/program/data in a 32-bit Windows environment.

What operating system(s) this bug have occurred on?

Windows 11 64-bit 25H2

What version(s) of DOSBox-X have this bug?

2025.12.01 Commit 10a5ce7 (Visual Studio SDL1 64-bit)

Used configuration

[sdl]
windowposition    = 
output            = ttf
clip_key_modifier = none

[dosbox]
language                 = es_ES
isa memory hole at 512kb = false
nocachedir               = true

[cpu]
core    = dynamic
cputype = pentium
cycles  = max

[mixer]
rate = 44100

[midi]
samplerate = 44100

[sblaster]
oplrate = 44100

[gus]
gusrate = 44100

[speaker]
pcrate    = 44100
tandyrate = 44100

[serial]
serial1 = directserial

[parallel]
parallel1 = file append:C:\Users\PCA\filename.txt

[printer]
printoutput = printer

[dos]
hard drive data rate limit   = 0
floppy drive data rate limit = 0
file access tries            = 3
ver                          = 7.1
autofixwarning               = true
starttranspath               = false
keyboardlayout               = sp
dos clipboard api            = true

[ne2000]
macaddr = AC:DE:48:88:99:AA

[4dos]

[config]
fcbs        = 100
files       = 200
country     = 34,858
set path    = Z:\;Z:\SYSTEM;Z:\BIN;Z:\DOS;Z:\4DOS;Z:\DEBUG;Z:\TEXTUTIL
set prompt  = $P$G
set temp    = 

[autoexec]
MOUNT F E:\
F:
CD\VENTAS
SET LPT1=LPT1
SET TAB-FILE.DAT=TAB-FILE.DAT
SET LOC-STOC.DAT=LOC-STOC.DAT
SET COSTO.DAT=COSTO.DAT
KEYB SP 850

Output log

Relevant excerpt from the official DOSBox-X build log:

1938122743       FILES:Special file open command 40 file F:\VENTAS\LOC-FACT.DAT
1938129299 DEBUG FILES:Seeking to 0 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938129430 DEBUG FILES:Reading 256 bytes from VENTAS\LOC-FACT.DAT
1938132031 DEBUG FILES:Seeking to 0 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938132162 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1938283761 DEBUG FILES:Seeking to 0 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938283892 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1938285495 DEBUG FILES:Seeking to 1326053376 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938285626 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1938287485 DEBUG FILES:Seeking to 1325959168 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938287616 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1938291747 DEBUG FILES:Seeking to 2055124992 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938291878 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1938295337 DEBUG FILES:Seeking to 2146813952 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1938295468 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1974941524 DEBUG FILES:Seeking to 0 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1974941655 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1974943674 DEBUG FILES:Seeking to -2146435072 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1975053217 DEBUG FILES:Seeking to 0 bytes from position type (0) in VENTAS\LOC-FACT.DAT
1975053348 DEBUG FILES:Reading 2048 bytes from VENTAS\LOC-FACT.DAT
1975058609       FILES:Closing file VENTAS\LOC-FACT.DAT

The important part is that position type (0) appears to be an absolute seek, but the logged target becomes negative once the file position crosses the 2 GiB boundary.

Additional information

This appears to be specific to DOSBox-X mounted host file handling rather than to the DOS application itself.

I tested the same DOS runtime, program, and data outside DOSBox-X in a 32-bit Windows environment and it works correctly.

I also locally investigated the problem in src/dos/drive_local.cpp and tested a source-modified build of my own for investigation purposes. With that build, the same scenario no longer reproduced and the program completed successfully.

I am not claiming that my local source change is necessarily the final upstream fix, only that it appears to confirm the problem is in DOSBox-X mounted local file positioning for files above 2 GiB.

This may be related in a broad sense to older >2GB storage issues, but my case is specifically about a host-mounted file accessed through a mounted drive, not a disk image format such as VHD/QCOW2 or an IMG-mounted disk.

If useful, I can also provide:

• the full official build log
• the minimal modified config
• notes from the local source investigation in src/dos/drive_local.cpp

largefile.log

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[maron2000]

You can of course share your findings to improve emulation.

[Andresmaga]

Thanks. Here are my findings.

I reproduced the problem on the official 2025.12.01 Visual Studio SDL1 64-bit build with a mounted host file slightly above 2 GiB.

In the official build log, the important symptom is that an absolute seek eventually becomes negative:

Seeking to 2146813952 bytes from position type (0) in VENTAS\LOC-FACT.DAT
...
Seeking to -2146435072 bytes from position type (0) in VENTAS\LOC-FACT.DAT

Since position type (0) appears to be an absolute seek, this looks like a signed 32-bit overflow/sign-conversion issue in the mounted local file path.

I investigated src/dos/drive_local.cpp locally and tested a source-modified build. In my local testing, the problem no longer reproduced after:

• replacing fseek/ftell usage in the affected local file path with fseeko64/ftello64
• replacing SetFilePointer with SetFilePointerEx on Windows
• treating SEEK_SET as an absolute unsigned offset, while SEEK_CUR and SEEK_END remain signed-relative offsets

I want to be careful here: I am not suggesting that this is necessarily the correct final upstream fix. My understanding is that changes in this area could affect other users or code paths.

I am only sharing this as a diagnostic patch from my local investigation, since it made the issue disappear in my testing and seems consistent with the negative absolute seek shown in the official-build log.

For reference, my local investigation was done against current source at commit 8d8c491 (8d8c491dfe22296678fc64fca8ce3c4370e6c8d0).

This is the clean diff from my local investigation against that source state:

diff --git a/src/dos/drive_local.cpp b/src/dos/drive_local.cpp
index f410fa2..b8daa0a 100644
--- a/src/dos/drive_local.cpp
+++ b/src/dos/drive_local.cpp
@@ -2800,7 +2800,7 @@ bool LocalFile::Read(uint8_t * data,uint16_t * size) {
 			off_t pos = lseek(fileno(fhandle),0,SEEK_CUR);
 			if (pos>-1) lseek(fileno(fhandle),pos,SEEK_SET);
 		} else
-			fseek(fhandle,ftell(fhandle),SEEK_SET);
+			fseeko64(fhandle,ftello64(fhandle),SEEK_SET);
         if (!newtime) UpdateLocalDateTime();
     }
 	last_action=READ;
@@ -2852,11 +2852,11 @@ bool LocalFile::Write(const uint8_t * data,uint16_t * size) {
 		if (file_access_tries>0) {
 			off_t pos = lseek(fileno(fhandle),0,SEEK_CUR);
 			if (pos>-1) lseek(fileno(fhandle),pos,SEEK_SET);
-		} else fseek(fhandle,ftell(fhandle),SEEK_SET);
+		} else fseeko64(fhandle,ftello64(fhandle),SEEK_SET);
 	}
 	last_action=WRITE;
 	if (*size==0){
-		uint32_t pos=file_access_tries>0?lseek(fileno(fhandle),0,SEEK_CUR):ftell(fhandle);
+		uint32_t pos=file_access_tries>0?(uint32_t)lseek(fileno(fhandle),0,SEEK_CUR):(uint32_t)ftello64(fhandle);
 		return !ftruncate(fileno(fhandle),pos);
 	} else {
 		*size=file_access_tries>0?(uint16_t)write(fileno(fhandle),data,*size):(uint16_t)fwrite(data,1,*size,fhandle);
@@ -2979,6 +2979,12 @@ bool LocalFile::LockFile(uint8_t mode, uint32_t pos, uint16_t size) {
 }
 
 extern const char* RunningProgram;
+static int64_t DOSSeekOffsetFromRaw(const uint32_t raw_pos, const uint32_t type) {
+    return type == DOS_SEEK_SET
+        ? static_cast<int64_t>(raw_pos)
+        : static_cast<int64_t>(static_cast<int32_t>(raw_pos));
+}
+
 bool LocalFile::Seek(uint32_t * pos,uint32_t type) {
 	int seektype;
 	switch (type) {
@@ -2992,11 +2998,17 @@ bool LocalFile::Seek(uint32_t * pos,uint32_t type) {
 #if defined(WIN32)
     if (file_access_tries>0) {
         HANDLE hFile = (HANDLE)_get_osfhandle(_fileno(fhandle));
-        DWORD dwPtr = SetFilePointer(hFile, *pos, NULL, type);
-        if (dwPtr == INVALID_SET_FILE_POINTER && !strcmp(RunningProgram, "BTHORNE"))	// Fix for Black Thorne
-            dwPtr = SetFilePointer(hFile, 0, NULL, DOS_SEEK_END);
-        if (dwPtr != INVALID_SET_FILE_POINTER) {										// If success
-            *pos = (uint32_t)dwPtr;
+        LARGE_INTEGER move;
+        LARGE_INTEGER result;
+        BOOL seek_ok;
+        move.QuadPart = DOSSeekOffsetFromRaw(*pos, type);
+        seek_ok = SetFilePointerEx(hFile, move, &result, seektype);
+        if (!seek_ok && !strcmp(RunningProgram, "BTHORNE")) { // Fix for Black Thorne
+            move.QuadPart = 0;
+            seek_ok = SetFilePointerEx(hFile, move, &result, DOS_SEEK_END);
+        }
+        if (seek_ok && result.QuadPart >= 0 && static_cast<uint64_t>(result.QuadPart) <= UINT32_MAX) {
+            *pos = static_cast<uint32_t>(result.QuadPart);
             return true;
         }
         DOS_SetError((uint16_t)GetLastError());
@@ -3004,15 +3016,16 @@ bool LocalFile::Seek(uint32_t * pos,uint32_t type) {
     }
 #endif
 	bool fail;
+    const int64_t seek_offset = DOSSeekOffsetFromRaw(*pos, type);
 	if (file_access_tries>0) fail=lseek(fileno(fhandle),*reinterpret_cast<int32_t*>(pos),seektype)==-1;
-	else fail=fseek(fhandle,*reinterpret_cast<int32_t*>(pos),seektype)!=0;
+	else fail=fseeko64(fhandle,seek_offset,seektype)!=0;
 	if (fail) {
 		// Out of file range, pretend everything is ok
 		// and move file pointer top end of file... ?! (Black Thorne)
 		if (file_access_tries>0)
 			lseek(fileno(fhandle),0,SEEK_END);
 		else
-			fseek(fhandle,0,SEEK_END);
+			fseeko64(fhandle,0,SEEK_END);
 	}
 #if 0
 	fpos_t temppos;
@@ -3020,7 +3033,7 @@ bool LocalFile::Seek(uint32_t * pos,uint32_t type) {
 	uint32_t * fake_pos=(uint32_t*)&temppos;
 	*pos=*fake_pos;
 #endif
-	*pos=file_access_tries>0?(uint32_t)lseek(fileno(fhandle),0,SEEK_CUR):(uint32_t)ftell(fhandle);
+	*pos=file_access_tries>0?(uint32_t)lseek(fileno(fhandle),0,SEEK_CUR):(uint32_t)ftello64(fhandle);
 	last_action=NONE;
 	return true;
 }
@@ -3099,7 +3112,7 @@ uint16_t LocalFile::GetInformation(void) {
 
 
 uint32_t LocalFile::GetSeekPos() {
-	return file_access_tries>0?(uint32_t)lseek(fileno(fhandle),0,SEEK_CUR):(uint32_t)ftell( fhandle );
+	return file_access_tries>0?(uint32_t)lseek(fileno(fhandle),0,SEEK_CUR):(uint32_t)ftello64(fhandle);
 }
 
 LocalFile::LocalFile() {}

Thanks in advance for taking a look.