Text 2584, 151 rader
Skriven 2011-04-02 15:16:45 av Jonathan de Boyne Pollard
Ärende: Re: formatting to FAT32
===============================
Gecko/20110303 Thunderbird/3.1.9
comp.os.os2.beta,comp.os.os2.utilities,comp.os.os2.programmer.misc,comp.os.os2.misc

UTC)
comp.os.os2.utilities:156 comp.os.os2.programmer.misc:2071
comp.os.os2.misc:3118
From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>

 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);
}



--- Internet Rex 2.31
 * Origin: virginmedia.com (1:261/20.999)