Sanitising DOSFS

It would appear that DOSFS (or maybe RISC OS itself) can’t cope too well with a device >2GiB?
Files placed onto a 4GiB USB key ‘vanished’ and the resultant filesystem errors choked chkdsk for about ten minutes! Luckily nothing of great value was on that device. I noticed the OMAP installation instructions say not to use anything over 2GiB.

Thus… my wishlist request is simple. Tweak DOSFS so that if you plug in a device that is too large to be handled, RISC OS will pop up an error and refuse to mount the device. This saves the… issues… involved in writing to the device when the OS obviously can’t correctly cope with it.

Best wishes,

Rick.

DOSFS can’t handle drives over 2GB.

I agree that perhaps some sort of warning would be nice.

If you want to use a bigger drive use the FAT32fs module

Rick, this problem was solved several years ago. Put Fat32FS on your Iyonix or BeagleBoard, and everything that you want happens.

Isn’t it time to negotiate including Fat32Fs in the official RISC OS ROM image? Persevering with something which was cobbled together in the days of floppy discs and has a number of known serious flaws is just silly. I note EtherUSB has just been integrated.

^^ what he said.

Silly me, expecting DOSFS to, you know, work. ;-)

It’s nice to know FAT32FS exists, I’ll install that tomorrow. However, I still believe, given that DOSFS can go badly wrong on >2GiB, that it ought to warn & reject as a matter of course, rather than blindly proceed and get it horribly wrong.

User storage should, as far as possible, be considered sacrosanct. It’s one thing to crash and lose work-in-progress. It’s quite something else to screw up an entire filesystem…

Best wishes,

Rick.

I think there are a couple of issues with using FAT32FS in the ROM itself.

1. It is GPL.

2. (As I understand it) It only works on USB. (So as it stands, DOSFS would still be needed.)

Would it be possible to split the ROM into parts?

So you would have the main core, and separate files for modules that you want in ROM, but which have incompatible licenses.

So you might have:
RISCOS, GPL and vendor files. (The extra files shouldn’t need to be specific to one machine.)

An after thought, could the ResourcesFS boot also be separated off by such a system?

Oh look, there’s those three initials again – GPL. So if the ROM is not an option, perhaps as a component in !Boot? Or would the inclusion of a GPL part require the entirety to e GPLised?

AIUI (and IANAL):

There is no need for Fat32FS to be included in the ROM. It could full well be included in the HardDisc4 image, where it does NOT need to be linked and therefore does not impose the GPL on the other software in the image.

If anyone knows differently, please correct me.

Would it be possible to split the ROM into parts?

As I said in another post recently, you can do this via podule ROM images.

Or would the inclusion of a GPL part require the entirety to e GPLised?

No. There’s a lot of GPL FUD circulating on these forums, hopefully this very basic explanation will help a bit. Clearly, this is just a very simple summary of something which is actually several pages worth of legal text, so it’s never quite this easy! But…

If your binary GPL code is linked against some other binary, then that something else must also have its source code published under the GPL. If you don’t follow that step, then you’ve violating the GPL in using the GPL software in whatever binary thing you’ve created. If you simply put a GPL binary into a disc image, clearly that doesn’t affect all of the other stuff in the disc image or nobody would ever have closed-source programs installed onto GPL’d operating systems.

The problem with linked against is that the person who wrote that clause had evidently never heard of RISC OS and its relocatable modules. What is the conventional interpretation of the licence WRT distributing a self-contained binary component which stands alone in a massive binary blob (i.e. a ROM image) which interacts with it only by means of SWI calls? There’s none of the mutual compile-time dependency that the phrase “linked against” implies.

As I said in another post recently, you can do this via podule ROM images.

I though that was what you meant, but is that the only way? (You mentioned the problem of intialisation order.)

What is the conventional interpretation of the licence WRT distributing a self-contained binary component which stands alone in a massive binary blob?

I’m sure that would be asking for trouble. But if two blobs are possible (especially if the non GPL one works on its own), surely that is the way to go?

If your binary GPL code is linked against some other binary, then that something else must also have its source code published under the GPL.

In other words, you can’t legitimately port anything GPL that works with SharedCLib…?

If you produce a ROM with a ‘hole’ in the middle for a module. And that module has defined entry points from which it returns after defined behaviour and the module does not jump into absolute memory address within the ROM but only uses SWI calls or documented system vectors. Then the module can use GPL protected chunks (as it is not linked to any other code just vector addresses and system calls at compile time) without any requirement to publish anything about the ROM. Otherwise you would have to document Windows if you used any GPL coded application under it which is obviously not intended.

All my software can be distributed under the terms of the BSD licence.

So, back to my original question…

Fat32FS is based on EFSL, which is GPL. So no BSD here.