File system improvements (Step 1)

The ‘on-disc’ format allows for files up to 4GB, but the implementation restricts this to only 2GB. By removing this restriction the file size limit is increased without the need to reformat preexisting discs.

This is a desirable improvement, but what are the implications if such a disc was used on a current machine (e.g. a USB drive, or perhaps an RPC or Iyonix, which only only has the new facility with a softload.)

Is it something that is likely to be loaded as a module? In which case any such discs could have an app in the root that softloads the module if needed.

This is a desirable improvement, but what are the implications if such a disc was used on a current machine (e.g. a USB drive, or perhaps an RPC or Iyonix, which only only has the new facility with a softload.)

If this fix will cause old OS versions to break, then I’m assuming it will be relatively easy to make a change to the disc record/root directory that will stop old OS’s from identifying the disc. You wouldn’t be able to access the disc on an old OS version, but it’s probably better than having it crash or corrupt the disc when it encounters a large file.

Is it something that is likely to be loaded as a module? In which case any such discs could have an app in the root that softloads the module if needed.

I think it should be possible to softload the required modules, but it’s not something I’ve ever tried before. Plus if the disc has to be made unrecognisable to old OS’s then reading the support modules from the disc could be a bit tricky! It would probably be better to wait for partition support to appear, at which point e.g. a RiscPC could have a RISC OS 3.5 compatible boot partition containing the support modules (and perhaps a full ROM softload) to allow access to the new format RISC OS 5 partition.

Hopefully, the presence of a large file will have no effect outside the folder it is in (even more hopefully the only problem would be an inability to use the large file itself). (This is what happened when I tried to copy a large file between a fat disks).

Then the required software could be included when a memory stick is going to be used on other machines.

If there are serious complications, then the fix will need to be able to be disabled.

This is a desirable improvement, but what are the implications if such a disc was used on a current machine

For harddiscs I think the number of instances where you need to remove the drive and retrospectively access it from an older machine is relatively rare (the other way round, migrating your old data to a new machine, is far more common).

Depending on the nature of the limitation it may even be possible to make a ROM patch (3.60 & 3.70 already have a FileCore patch for the ADFSBuffers=255 problem, and 4.02 have ROM patches too in the boot sequence). FileCore can be softloaded, even off a FileCore based filing system: you just load it into RAM then do OS_Module-insert-from-RAM on it.

For harddiscs I think the number of instances where you need to remove the drive and retrospectively access it from an older machine is relatively rare

What about softloading the OS or booting before the patch is loaded?

The questions that need to be answered are:

Will the presence of a file over 2GB cause an issue when it is in an unopened folder?

Will it cause an issue in an opened folder (or root)?

Will it only cause an issue if it is accessed?

Will these issues damage the file system?

Even if the answers aren’t good, it is still very a worthwile improvement, but knowing these answers is very important, to know how to use it, and whether it needs the option of an artificial cap of 2GB, for interoperability.

What about softloading the OS or booting before the patch is loaded?

Your questions will probably have yes/no answers once someone collects the bounty, but my bet would be that as long as the boot sequence (up to the point of the patch) didn’t encounter any files > 2G it’d be fine.

I suspect having clear answers might interest more people in adding to the bounty.

As I see it the worst possibility is mounting a drive with a large file on an existing system would cause data corruption, the best possibility is count won’t work correctly and copy won’t even try.

If situation is at the worst end, then it will be of of little benefit to RPC users (unless there are blocks on putting big files on the boot drive), and will only be of use to Iyonix users once it is in a new ROM. (Obviously it would be fine for BB users.)

If it is at the best end, then all systems would benefit.

I suspect having clear answers might interest more people in adding to the bounty.

Not sure that logic holds water:

• don’t add to the bounty → definitely nobody benefits
• do add to the bounty → benefit for users of 5.xx, possibly for others

Another way to think about it is:
I want to build a garage on my house. I tell the builder I’ll only hire him if first he digs the foundation and pours the concrete (so that I’m sure my extension will be able to support my car’s weight) for free.
Oddly, no builders tender for the work.

I would think of it more like asking, “will my existing house fall down?” To which the builder would take a look at the existing structure, and answer “Of course not”, or “you need to rebuild this as well too”, he may even do a couple of tests."

Please don’t confuse my wanting to know this answer for me not wanting this improvement, it is quite a big one for me, because it would make CDVDBurn a viable upgrade for me.

For anyone with a beagleboard, this will be a simple improvement, it doesn’t matter what an old OS would make of a large file, because they won’t need to use one.

For Iyonix and RPC users, this does matter. If the situation is “don’t open a folder with big files on a non enhanced OS” then this is a useful upgrade imediately.

If it is a case of “don’t mount a disk with big files on a non enhanced OS”, then it would only be of use (on the local drive) with a new flash, or partition support.

Obviously there will be obvious knock on benefits, if big files work on filecore, then they will also work on CDFS and FAT32FS etc.

Please don’t confuse my wanting to know this answer for me not wanting this improvement

Understood.

I’m trying to emphasise that the 1st bounty includes documenting and assessing the current state of play as well as making the actual code changes – from which answers (and design decisions) come, and that these answers can only be certain once someone collects the bounty. We’ve had 3 years of guesswork and speculation, there’s probably not much to be gained by producing more without the facts.

That makes sense now. Going back to your analogy, the building needs a structural survey first.

An obvious design decision will be whether an artifical cap to the old size needs to be an option and what locations it needs to be able to be applied to.