www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/01/11/12:55:53

From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199901111754.SAA02061@father.ludd.luth.se>
Subject: Re: FAT32
To: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date: Mon, 11 Jan 1999 18:54:29 +0100 (MET)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

Eli said:
> Btw, what happens if you issue a FAT32-related call on a FAT16 disk?
> Maybe we could use the new functions unconditionally in some cases?

Yes! Indeed it seems to work on FAT32, FAT16 and a from samba mounted
file system. Only my FAT32 file system is big enough to be able to
hold files bigger than 2^31.

Here's a hand typed patch for src/libc/dos/io/_open.c:
 if(use_lfn) {
   r.x.ax = 0x716c;
-  r.x.bx = oflag & 0xff;
+  r.x.bx = (oflag & 0xff) | 0x1000;
   r.x.dx = 1;                        /* Open existing file */

It's hopefully evident so you can apply by hand if I misstyped
somehow. This makes _open to always use the extended bit in the LFN
case. Please try it out. Unless somebody finds any trouble I suggest
we do it like this. If so, no more trying to detect FAT32 is
necessary. Or have I missed something?

There are of course other places this "| 0x1000" should be added as
well. But for testing out this should be sufficient (You have to
_open() existing files).


Right,

							MartinS

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019