On 23 Oct, Matthew Howkins <[email protected]> wrote:
> > Ah, that's a frequently called out myth.
> > In PRM 5a (in the section 'FileCore') the overview section describes the
> > limitations present, at RISC OS 3.70 at least. To paraphrase:
> >
> > Filecore = max file size 2^31 -1
> > FileSwitch = max file size 2^32 -1
> >
> > as HostFS is a FileSwitch client it should be able to support 4G files as
> > far back as RISC OS 3.70.
>
> I performed
> my testing with both RISC OS 4.02 and RISC OS 5. I used a version of HostFS
> that fully supported large files (on 64-bit Linux this support is enabled
> as an inherent feature of a 64-bit executable).
I'm on 32 bit WinXP, for reference.
> My first test was to copy a 3GB file to a new file using the Filer. This
> immediately failed on RISC OS 4.02 with an error 'No readable memory at
> this address'.
>
> A glance at the source code of RISC OS 5 shows that the FilerAction code
> uses a signed 32-bit integer to keep track of file sizes and copy
> progress [...] I will assume that all other versions of RISC OS
> contain the signed variant - this seems reasonable based on my testing.
>
> RPCEmu is also used to run a lot of old/legacy applications. Those which
> are
> coded in C and using the standard C API will not support files >=2GB, and
> if they are presented with files of this size will probably fail in
> unpredictable ways.
>
> Given the constraints listed above, I am not willing to accept your
> changes as the support for up to 4GB files simply will not work for the
> vast majority of RPCEmu users.
I'm not sure that the order that you performed your test has resulted in any
new conclusions being drawn. There certainly were a few hidden gotchas in
FilerAction, and no doubt other people's code compares signed numbers
inappropriately too.
Because of the modular nature of RISC OS, there's nothing stopping someone
softloading the C Library (as many do for long long extensions) or
FilerAction (maybe for its funky progress bar). It'd be a shame if the
underlying HostFS didn't follow the capabilities advertised in the PRM.
Here are the tests I think would be more illustrative
1. Vanilla 0.8.8 with vanilla 4.02
*CREATE bigfile C0000000
Try to copy it with Filer Action
Note the outcome
2. Updated HostFS on 0.8.8 with vanilla 4.02
*CREATE bigfile C0000000
Try to copy it with Filer Action
Note the outcome
3. Vanilla 0.8.8 with updated 5.17 (can provide if not downloadable yet)
*CREATE bigfile C0000000
Try to copy it with Filer Action
Note the outcome
4. Updated HostFS on 0.8.8 with updated 5.17
*CREATE bigfile C0000000
Try to copy it with Filer Action
Note the outcome
If (2) is same outcome or better than (1), and (4) is definitely better than
(3), then the patch to HostFS has not made anything worse nor broken
anything,
Sprow.
Footnote: It's fine to hold 32 bit file extents in signed numbers, even add
and subtract stuff from them, it's only comparison operations that screw up.
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
