Groups | Search | Server Info | Login | Register


Groups > comp.os.os2.programmer.misc > #137

Re: formatting to FAT32

From Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>
Newsgroups comp.os.os2.beta, comp.os.os2.utilities, comp.os.os2.programmer.misc, comp.os.os2.misc
Subject Re: formatting to FAT32
References (7 earlier) <slrnipa2qd.uqm.nospam-abuse@powdermilk.math.berkeley.edu> <IU.D20110401.T011141.P31426.Q0@J.de.Boyne.Pollard.localhost> <4D95CB7D.2060206@chollian.net> <IU.D20110401.T183722.P49800.Q0@J.de.Boyne.Pollard.localhost> <YEdw17zDmnZd-pn2-Rc2UVCMFU0i9@0605ds7-suoe.2.fullrate.dk>
Message-ID <IU.D20110402.T141716.P52711.Q0@J.de.Boyne.Pollard.localhost> (permalink)
Organization virginmedia.com
Date 2011-04-02 15:16 +0100

Cross-posted to 4 groups.

Show all headers | View raw


 These bugs have been known for years, as you can see on the data of 
> the msgs. Doesn't look like anyone has been working on it.
>
Well M. Ko has the ability to modify, recompile, and use FAT32.IFS, so 
let's introduce FS_CHGFILEPTRL and see whether it fixes the problem M. 
Ko stated that xe didn't know why this was happening. Here's a 
hypothesis that seems reasonable. The data that we have are these:

* Raw access with DosRead/DosWrite/DosSetFilePtr works just fine on your 
~4GiB FAT32 volume.
* DosSetFilePtr() returns ERROR_SEEK on larger FAT32 volumes.
* M. Ko reports that the FS_CHGFILEPTR function of the IFS isn't even 
being called in such circumstances.

The thing to remember, to start with, is that the whole "sector mode" 
thing is a red herring. That's purely within the IFS driver itself. The 
kernel knows nothing of it. As far as the kernel is concerned raw access 
is *always* byte-by-byte and offsets are byte offsets. Once one gets 
one's head around that, then a hypothesis positively leaps out. The OS/2 
version 4.5 kernel, remember, has 64-bit file pointer support. So it's a 
fair chance that what's happening is that the kernel is saying "Oho! The 
application is trying to move the file pointer about, and this disc 
volume is larger than 4GiB. So I'll use 64-bit file pointer 
mechanisms.". The problem in such a circumstance is that FAT32.IFS 
doesn't have a FS_CHGFILEPTRL entrypoint. The kernel sees a non-existent 
entrypoint, and rather than falling back to the 32-bit one it simply 
returns ERROR_SEEK.

By the way, in answer to the other question that came up all those years 
ago: If you look at the VirtualBox shared folders OS/2 IFS driver 
skeleton code, you'll see three out of four entrypoints complete with 
function signatures. The four entrypoints are thus FS_CHGFILEPTR, 
FS_CHGFILEPTRL, FS32_CHGFILEPTR, and FS32_CHGFILEPTRL. The entrypoints 
ending in "L" take a 64-bit file offset value instead of a 32-bit one, 
and the entrypoints beginning "FS32_" are 32-bit functions instead of 
16-bit ones.

If this hypothesis is correct — and it's a fairly credible one — then 
giving the kernel an actual "L" entrypoint to call when it wants to seek 
around within a >4GiB volume will stop the ERROR_SEEKs. Making such a 
function is dead easy. Just copy FS_CHGFILEPTRL, change the lOffset 
parameter to a 64-bit signed integer, and (for now) add a check on the 
desired to position to ensure that it is less than 0x1_0000_0000. Then 
set the FSA_LARGEFILE attribute. This might necessitate doing 
FS_NEWSIZEL, FS_CANCELLOCKREQUESTL, and FS_FILELOCKSL, as well; but the 
same approach applies. Indeed, one could *rename* the non-"L" functions 
to the "L" functions and then make the non-"L" functions into wrappers 
that call the "L" functions. Something like the code at the end of this 
message, which is off the top of my head, perhaps. (I suggest that those 
with JFS source code access check what SFFSI structure is passed to an 
"L" function.)

M. Ko has the ability to modify, recompile, and use FAT32.IFS, and you 
apparently have JFS source code access. If xe does that, and you check 
the SFFSI structure, I can supply CHKVOL to test against a >4GiB volume.

int far pascal FS_CHGFILEPTRL(
     struct sffsi far * psffsi,		/* psffsi	*/
     struct sffsd far * psffsd,		/* psffsd	*/
     LONGLONG lOffset,			/* offset	*/
     unsigned short usType,		/* type		*/
     unsigned short IOFlag		/* IOflag	*/
)
{
PVOLINFO pVolInfo;
POPENINFO pOpenInfo = GetOpenInfo(psffsd);
LONGLONG  lNewOffset;
USHORT rc;

    if (f32Parms.fMessageActive&  LOG_FS)
       Message("FS_CHGFILEPTRL, Mode %d - offset %lld, current offset=%lu",
       usType, lOffset, psffsi->sfi_position);

    pVolInfo = GetVolInfo(psffsi->sfi_hVPB);
    if (IsDriveLocked(pVolInfo))
       return ERROR_DRIVE_LOCKED;

    switch (usType)
       {
       case CFP_RELBEGIN :
          if (lOffset<  0)
             {
             rc = ERROR_NEGATIVE_SEEK;
             goto FS_CHGFILEPTRLEXIT;
             }
          lNewOffset = lOffset;
          break;
       case CFP_RELCUR  :
          lNewOffset = psffsi->sfi_position + lOffset;
          break;
       case CFP_RELEND	:
          lNewOffset = psffsi->sfi_size + lOffset;
          break;
       }
    if (!IsDosSession()&&  lNewOffset<  0)
       {
       rc = ERROR_NEGATIVE_SEEK;
       goto FS_CHGFILEPTRLEXIT;
       }
    /* This ensures that all positions are in the first 4GiB, preserving
       the semantics of 32-bit file pointers.  Of course, with true large
       file support, this test is unnecessary and wrong.  But we're not
       setting out to do that at the moment.  */
    if (lNewOffset>  (ULONGLONG)0xFFFFFFFF)
       {
       rc = ERROR_NEGATIVE_SEEK;
       goto FS_CHGFILEPTRLEXIT;
       }

    /* Yes, we're casting to a ULONGLONG and then assigning into a ULONG.
       This is so that we don't have to revisit this down the line.  */
    if (psffsi->sfi_position != (ULONGLONG)lNewOffset)
       {
       psffsi->sfi_position = (ULONGLONG)lNewOffset;
       pOpenInfo->ulCurCluster = FAT_EOF;
       }
    rc = 0;

FS_CHGFILEPTRLEXIT:
    if (f32Parms.fMessageActive&  LOG_FS)
       Message("FS_CHGFILEPTRL returned %u", rc);
    return rc;
}

int far pascal FS_CHGFILEPTR(
     struct sffsi far * psffsi,		/* psffsi	*/
     struct sffsd far * psffsd,		/* psffsd	*/
     LONG lOffset,			/* offset	*/
     unsigned short usType,		/* type		*/
     unsigned short IOFlag		/* IOflag	*/
)
{
     /* The 32-bit function simply devolves to the 64-bit one.
        If the SFFFSI structures differ, we might not be able to
        do things this simply, and might have to cut and paste
        instead.  */
     return FS_CHGFILEPTRL(psffsi, psffsd, lOffset, usType, IOFlag);
}

Back to comp.os.os2.programmer.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-01 02:11 +0100
  Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-01 21:56 +0900
    Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-01 19:37 +0100
      Re: formatting to FAT32 "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-02 10:21 +0200
        Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-02 15:16 +0100
          Re: formatting to FAT32 Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-04-02 21:49 +0000
            Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 02:17 +0100
              Re: formatting to FAT32 Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-04-03 09:17 +0000
                Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 19:51 +0100
          Re: formatting to FAT32 "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-03 00:12 +0200
            Re: Is JFS really open source? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 01:50 +0100
              Re: Is JFS really open source? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 19:32 +0100
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-03 14:04 -0700
                Re: Is JFS really open source? Steve Wendt <spamsux@forgetit.org> - 2011-04-03 15:51 -0700
                Re: Is JFS really open source? "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-04 01:24 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-04 11:22 +0200
                Re: Is JFS really open source? Anonymous <nobody@remailer.paranoici.org> - 2011-04-04 16:44 +0200
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-04 09:03 -0700
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-05 17:15 +0200
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-05 16:29 -0700
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 04:16 +0200
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-10 19:28 -0700
                Re: Is JFS really open source? what.ever@neverm.ind (A.D. Fundum) - 2011-04-11 05:06 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 07:07 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 07:25 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-25 12:20 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 02:34 +0200
              Re: Is JFS really open source? "Alex Taylor" <mail.me@reply.to.address> - 2011-04-04 09:51 -0500
                Re: Is JFS really open source? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-05 19:51 +0100
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-05 16:34 -0700
                Re: Is JFS really open source? "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com> - 2011-04-06 01:05 +0000
                Re: Is JFS really open source? "Alex Taylor" <mail.me@reply.to.address> - 2011-04-08 04:24 -0500
                Re: Is JFS really open source? Paul Ratcliffe <abuse@orac12.clara34.co56.uk78> - 2011-04-08 11:49 +0000
                Re: Is JFS really open source? "Alex Taylor" <mail.me@reply.to.address> - 2011-04-10 01:26 -0500
                Re: Is JFS really open source? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-08 21:03 +0100
                Re: Is JFS really open source? "Alex Taylor" <mail.me@reply.to.address> - 2011-04-10 01:25 -0500
                Re: Is JFS really open source? Dave Yeo <dave.r.yeo@gmail.com> - 2011-04-10 00:42 -0700
                Re: Is JFS really open source? "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-10 21:31 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-10 23:37 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-10 11:37 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-10 22:42 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 00:21 +0200
                Re: Is JFS really open source? "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-11 01:15 +0200
          Re: Does JFS work on OS/2 version 4.0 and earlier? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 22:29 +0100
            Re: Does JFS work on OS/2 version 4.0 and earlier? "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-04 01:31 +0200
              Re: Does JFS work on OS/2 version 4.0 and earlier? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-04 11:31 +0100
          Re: formatting to FAT32 Lars Erdmann <lars.erdmann@arcor.de> - 2011-04-04 20:57 +0200
            Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-05 15:09 +0100
              Re: formatting to FAT32 Lars Erdmann <lars.erdmann@arcor.de> - 2011-04-06 08:07 +0200
      Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-02 22:13 +0900
        Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-02 18:59 +0100
          Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-03 14:51 +0900
            Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 22:00 +0100
              Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-04 22:19 +0900
                Re: formatting to FAT32 "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-04 16:51 +0200
                Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-06 18:20 +0100
                Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-14 22:38 +0900
            Re: formatting to FAT32 "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com> - 2011-04-05 15:42 +0000
              Re: formatting to FAT32 "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-05 20:08 +0200
                Re: formatting to FAT32 "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com> - 2011-04-05 22:49 +0000
                Re: formatting to FAT32 "Allan" <allan2@warpspeed.dyndns.dk> - 2011-04-06 01:23 +0200
                Re: formatting to FAT32 "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com> - 2011-04-06 01:10 +0000
                Re: formatting to FAT32 KO Myung-Hun <komh@chollian.net> - 2011-04-06 21:49 +0900
                Re: formatting to FAT32 "Andy" <nospam-abwillis1-nopspam@nospam-gmail.com> - 2011-04-06 14:34 +0000
                Re: FAT32: SLOOOOOW Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-04-08 21:11 +0000
        Re: formatting to FAT32 Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-04-02 22:00 +0000
          Re: formatting to FAT32 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-04-03 02:32 +0100
      ZIP.IFS, LZH "A.D. Fundum" <what.ever@neverm.ind> - 2011-04-05 16:42 +0200

csiph-web