From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bryan J Smith Subject: Re: File Limits Date: Tue, 18 Jan 2011 09:35:09 -0800 (PST) Message-ID: <475908.23551.qm@web110806.mail.gq1.yahoo.com> References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295372109; bh=dHwWgItAbWxCXE8JnhQ5wOdWYhPR6mQpaP1n8XEz1Hc=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LeqEHxEG4ZY06ESH9Pi6zQyTCIqbSpDLSh13PdspZtUMWYQ3jPtNA0h1RjY7hPk95r7qblu3yVGjdFRptLOz6xHm51b+fOOuxkbMZR9caGITfzecPfWgfAndZxYixGGqgFYVtd9vxlp7yPgdbmtcCwRY7zY7Zh90aQpgceTNd9o= In-Reply-To: Sender: linux-msdos-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Xavier Tarifa , "linux-msdos@vger.kernel.org" All DOS (including DOS 7/Win 4 releases running in 386Enhanced mode -- Windows 95, 98, Me) only support 2GiB files IIRC. Even Real86 mode DOS 7 supports FAT32, which allows bigger than 2GiB _file_systems_, but still has the 2GiB-1 (signed 32-bit int) _individual_file_ size limitation IIRC. In fact, I don't think the 4GiB-1 (unsigned 32-bit int) support is in any DOS/Win releases. I only think it is an option in NT kernels (FAT16 in 3.1, 3.5, 3.51 and 4.0, FAT16 and FAT32 in 5.0/2000, 5.1/XP-2003, 6.0-Vista and 6.1/7-2008). And any program that uses it _must_ know about the NT-only Win32 function calls that offer this. I.e., the "Chicago" (Win9x) and NT/Win32 teams used _different_ DOS Int 21h and Win32[s] function calls, the former completely ignoring the pre-existing of the latter. "Chicago" _never_ supported the native NT/Win32 calls, hence why they likely _never_ supported the extensions for 4GiB-1 support IIRC.[1] One quick trip to TechNet and you'll note this is an issue in "bare metal" DOS/Win and even NT. The legacy "Chicago" DOS Int 21h file services don't handle growing beyond 2GiB-1 proper, _unless_ the NT/Win32 function extensions are utilized. Unfortunately even NT 5.0 (Windows 2000) implements the "Chicago" calls bug-for-bug for compatibility reasons. I.e., your program is likely instigating this, and the OS is just letting it do what it wants (and causing the issue). -- Bryan NOTES: [1] Like many libraries in NT/Win32, things just "didn't work" or "work well" under Win9x -- OpenGL being my personal favorite, and the whole "DirectMM -- aka Direct [DOS] Memory Map" lineage now known as "DirectX". It wasn't until NT 5.0 (Windows 2000) that the NT/Win32 team started also supporting the "Chicago"/Win32 DOS Int 21h changes. ----- Original Message ---- From: Xavier Tarifa So here's my problem: Until now I was using dosemu with ms-dos 6.22 to run an old database. A little while ago we had some big changes to the tables and they grew a lot. Yesterday I realized that we have a database file that is about to hit 2 Gb. I remembered that some time ago, we hit a bug on our program and it endlessly inserted rows on a table until it hit the 2 gb mark. Then the file either disappeared or became a 0 bytes file, I don't remember well. So I started reading and found that ms-dos 6.22 only supports FAT16 and apparently it only allows 2 gb volumes, and 2 gb files. So I thought of using ms-dos 7.10 which supports fat32 and would give us 4 gb files. But the same happens. The files disappear as soon as they hit the 2 gb mark. And when I execute the dir command, it always reports 2 gb of free disk space, which is odd. I don't know if this is a limitation of dosemu or I'm doing something wrong. Right now, I have about 140 users. On each $HOME/.dosemu/drive_c/ of the users there are symlinks to each file in /usr/share/dosemu/drive_z/ , where ms-dos is located. And I have the database files in /datos/ . I use lredir to make it appear as f: to every user. All of this is in the same ext3 partition. Any ideas?