PH>> ...Except, that the (DOS-based) DIR-command can not cope with large
 PH>> partitions??
 PH>> 
 PH>> Here's 4DOS in a DOS-box
 PH>> 
 PH>>   6.513.905 bytes in 40 files and 62 dirs  9.699.328 bytes allocated
 PH>>           0 bytes free
 PH>> 
 PH>> And now 4OS2 (same drive etc.) in [an OS/2 text-mode session]:
 PH>> 
 PH>>     6.516.188 bytes in 41 files and 62 dirs  6.558.720 bytes allocated
 PH>> 1.101.885.952 bytes free
 RB> You are using OS/2...  You must then be using IBM DOS...  I am thus
 RB> surprised that it cannot read large partitions [...]
It's clear, from the portion of his post quoted above, that OS/2 *can* cope 
with large partitions, because 4OS2 and FileCommander/2 are both *displaying 
the correct results*.  (In fact, OS/2 has been able to cope with partitions 
greater than 2GB since the days of OS/2 1.1, so there's no surprise there.)
The software that *isn't* coping with partitions larger than 2GB is 4DOS, 
specifically 4DOS version 5.52.  4DOS 6.01 has fixed this problem, and now 
displays the correct results (taking into account the assumption made by DOS 
that all filesystems use clustering in the same ways as FAT does). 
But then this isn't surprising.  The 2GB size bug in this form is *always* an 
application bug, and has been for almost a decade now, ever since people 
started using non-FAT filesystems, such as Novell Netware LANs, NFS mounts on 
UNIX boxes, and HPFS in OS/2.  The DOS INT 21h API itself is quite capable of 
returning information about partitions up to 2 Terabytes.  It is the 
applications, when they multiply the two unsigned, 16-bit, integer values 
returned to them by DOS and the size of a sector together using signed, 
32-bit, integers to hold the result, that introduce the size limit bugs.
 ¯ JdeBP ®
--- FleetStreet 1.19 NR
---------------