What file System does risc os use?

I wanted to know what file system does risc os use?

i had a look online https://www.riscosopen.org/wiki/documentation/show/Beginners%20FAQ:Hardware%20Support and it says it supports FAT16 and FAT32 as well as its own (FileCore) file system but which one does it actually use typically?

and i read this https://www.riscosopen.org/bounty/polls/9 but it is too complicated for me. can someone simplify it please?

ta

i had a look online https://www.riscosopen.org/wiki/documentation/show/Beginners%20FAQ:Hardware%20Support and it says it supports FAT16 and FAT32 as well as its own (FileCore) file system but which one does it actually use typically?

‘Typically’ is a bit tricky.

All the older build machines had ADFS (filecore based) as the default file system, other filecorebased file systems were available with alternate supplier drive interfaces.

New machines like the Pi, or beagleboard, panda board have different file systems as default SDFS, SCSIFS again filecore based. Plus the non-native stuff like FAT.

ta for the quick response.

so what does the pi use? different file systems? how? what determines what file system it uses?

Several. Your SD card will be using SDFS whereas USB drives use SCSIFS or FAT32 depending on how you formatted them. Since SD cards offer better performance than USB on the Pi it makes sense to partition your SD card for booting and file storage.

i have an sd card and just plugged it in and used win32 disk imager.

in my case it uses SDFS right?

might be a dumb question (forgive me) but whats the difference between SDFS and fat16/32?

Win32 disk imager is just a win proggy to help you writing an image file to an SD card. Nothing to do with the nature of the image itself. Under RISC OS you’ll see little drive icons on the left side of the Iconbar (Taskbar in MS parlance). Clicking them will open a filer window showing its content. It’ll also show you the filing system used: SDFS::RPi.$. etc.

just booted into vm put the sd card used fdisk -l to see whats its on and i got this.

Disk riscnew.dd: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0×00000000

riscnew.dd1 * 1 7 49152 b W95 FAT32
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(0, 0, 11)
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(6, 30, 34)
riscnew.dd4 7 240 1871867 ad Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(6, 30, 35)
Partition 4 has different physical/logical endings:
phys=(1023, 254, 63) logical=(239, 39, 56)

so running fat?

i mean fat32

What RISC OS machine are you using? (If, as strongly suggested by your previous post, you aren’t using one at all, then why on earth are you asking?)

What image file did you use with Win32DiskImager?

Does your question concern disc format or filing system? There is a difference. FileCore is the name of the standard RISC OS disc format – i.e. the arrangement of bytes in the image file you passed into Win32DiskImager. People have been giving you answers about filing system, which in RISC OS language refers to the program used to physically access the data on the disc. Obviously this changes according to whether the disc is on the other end of an SD, USB, IDE or CD interface.

Finally, if you downloaded a Raspberry Pi disc image (which, contrary to popular belief, is not the only kind available), be aware that they are craftily formatted to produce two different valid results depending on whether they are read by a program which expects FAT32 format data or one which expects FileCore format data (a kludge made necessary by the fact that FileCore doesn’t support partitions). It looks as if you’ve got a disc image in that dual format. Your fdisk program doesn’t know anything about FileCore, so it takes the FAT32 option. Plug it into a RISC OS system (which you have yet to suggest you have access to) and the results will be rather different.

i downloaded RISC OS from here http://www.raspberrypi.org/downloads from the link below risc os

oh i see. I now understand.

when you say " they are craftily formatted to produce two different valid results depending on whether they are read by a program which expects FAT32 format data or one which expects FileCore format data" how is it done? can you point me in the right direction to read up on it?

i’ll get the sd card in the pi and play with it later

when you say " they are craftily formatted to produce two different valid results depending on whether they are read by a program which expects FAT32 format data or one which expects FileCore format data" how is it done?

I have no idea. All I know is it’s heinously complicated, and I’m not absolutely convinced all of the implementation details have been made public.

can you point me in the right direction to read up on it?

No, but you can buy a program which does it here.

My understanding is that the current UBoot image that is used requires a DOS partition with a boot image on it.
RISC OS has no concept of partitions, and requires the entire device to be formatted in RISC OS format.
So what has been done is the partition table and DOS filesystem has been written to the disk in a RISC OS “File”, which can be found in !Boot.Loader.

Partition tables are the work of the devil, and playing with them unless you really know you’re not shit, and know your shit is going to end in disaster.
Add to that the fact you need to know RISC OS filesystems in a similar vein and you can see the world of pain that lies ahead.

Those tools at piccolo systems look seriously nice, I’ll have to invest…

It can be a bit confusing because what people mean by ‘filesystem’ and ‘filing system’ varies between platforms.

On RISC OS we have ‘filing systems’, which are commonly both the hardware driver (how to get blocks on and off disc, would be /dev/sda and similar in Linux) and decide how files are organised on the disc (what people would call ‘filesystems’ on other platforms).

In one common case this is split up, so ‘FileCore’ does the organisation and other ‘filing systems’ do the driver side. Some examples are SDFS, SCSIFS, IDEFS that all talk to the kind of hardware suggested by their names. When you see a filename like SDFS::DiscName.$.DirName.Filename it refers that it’s connected by some hardware controlled by SDFS and also (implicitly) a FileCore-formatted volume.

An alternative would be CDFS, which is the file organisation system for CDs and DVDs. They aren’t FileCore or FAT formatted, they’re ISO9660 formatted instead, which CDFS understands. CDFS doesn’t actually know how to talk to CD drives itself, it has its own special family of drivers instead (things like CDFSSoftATAPI and CDFSSoftSCSI2). This isn’t quite as stupid as it sounds because CDs are quite different from hard and flash drives anyway. However the mechanism by which CDFS talks to CDFSSoftSCSI2 is completely different to that by which FileCore talks to SCSIFS¹, which would be very annoying except that writing to CDs is awkward so we don’t use them in the same way.

RISC OS has another feature called ‘image filing systems’, where you can look at a file as a separate volume. For example, consider a Zip file or an ISO image – it’s a file that contains other files. It’s a better-integrated version of the way you can double click a Zip in Windows and it looks as if it’s a normal folder.

The Pi image is slightly more confusing. SDFS is the hardware driver, and it has both FileCore and FAT partitions – if you look at it on a PC you’ll see two partitions, FAT first then FileCore. RISC OS doesn’t do partitions, so it assumes the whole volume is FileCore formatted. It just so happens that the FileCore partition is created with one large file already existing, which just so happens to wrap up the FAT partition. So the PC sees the FAT area as a separate partition, RISC OS sees it as a large file inside an existing FileCore partition. Both are wrong, but this is sufficient to stop them meddling with the other’s areas.

Having defined the FAT partition as a large file, RISC OS just hands it over to DOSFS (which is an image filing system) which can open the FAT filesystem (but not FAT32) as a folder. So it looks like just another folder, but actually you’re accessing a different partition. It’s very clever, but also very nasty if it goes wrong. Don’t delete this folder or you’ll be in trouble.

¹ There is, in fact, a common SCSI layer that sits below them but most apps shouldn’t use that.

oh wow, it is more complex than i thought it was, but its very interesting.

thanks Theo Markettos, appreciate it.

when you say “which can open the FAT filesystem (but not FAT32)”

why not?

also, isnt the second fat partition fat32?

DOSFS can use FAT12 and FAT16 but not FAT32. It is to “old”. https://en.wikipedia.org/wiki/File_Allocation_Table

DOSFS can use FAT12 and FAT16 but not FAT32

Yes it can, since version 0.79, from September 2004.

Yes it can, since version 0.79, from September 2004.

I think the important thing from John’s point of view is that to understand the answers given you need to know the history/timeline.

http://en.wikipedia.org/wiki/RISC_OS
http://en.wikipedia.org/wiki/History_of_RISC_OS
https://en.wikipedia.org/wiki/File_Allocation_Table

Those will help, but the short story is that FAT support in DOSFS pre-dates Win95 which brought in FAT32. From this John should gather that substantially speaking RO pre-dates Win95.

It was better than Win95 before Win95. Unfortunately big money for development meant Winxxx added things RO doesn’t have.
On the other hand compare \windows\system32\shell32.dll and the RO ROM for size. Or even the whole !Boot plus ROM vs. MRT.exe (microsofts malicious software removal tool) on its own.

also (implicitly) a FileCore-formatted volume.

…and to elaborate on why this is important, RISC OS does not work with file extensions like Windows. A file does not indicate its type by its name, but rather by some metadata.
All files have metadata (that is, associated information on the file that is maintained by the operating system and not contained within the file itself) – creation date, last access date, access rights, etc. RISC OS takes this the logical step further to have the file’s type also represented in this way. I much prefer this to “.txt”, “.doc”, “.htm” and so on.

Unfortunately big money for development meant Winxxx added things RO doesn’t have.

I heard it said once, a long time ago, that RISC OS, the ARM processor, and the entire Archimedes chipset/design was all done on a budget smaller than Microsoft’s yearly expenditure on toilet paper.

Regardless of the accuracy of the statement, it does give a nod to the orders of magnitude difference in resources available to each. But, then, American companies seemed to think that problems could be overcome by adding more oomph. The late ‘90s and the AMD/Intel race was… insane. It was like each week that went by would bring a massive increase in capabilities …… yet, oddly, all this time down the line, using RISC OS on a GHz board feels like trying to catch a greased pig and having compiled code many times on an A3000, my jaw still drops slightly when I can build the entire operating system in maybe half an hour. And Windows? This is the odd part. Windows is a hell of a lot more capable, streaming HD animé would have been unthinkable back then (hell, we swapped VHS tapes!) but in use and the API in general, it doesn’t really feel that much faster. Sure, stuff happens more quality, but with RISC OS it is like the entire system is on a caffeine high, you can feel it. Windows, the extra power is apparent in the things you do but it seems like the interface runs like it always did, just slow enough to notice but not slow enough to annoy.

On the other hand compare \windows\system32\shell32.dll and the RO ROM for size.

I did a rough comparison of Windows 3.11 for Workgroups. Don’t know if it was in my “magazine” or elsewhere on my site; but I stripped RISC OS (3.7) down to its basics to have the minimum required for the OS with working desktop. I don’t recall exactly, but I think it added up to less than the kernel DLL. I then looked at what was offered on the hacked-with versions of Windows that boot from a floppy disc, and realising that I could probably get quite a bit more of RISC OS into the same space.

We are talking Windows 3. We are talking 1992 and “Program Manager”.

My installation of Windows XP fills the 4GB C:\ SSD (and “Program Files” is on D:\). I dread to think what Vista/7/8.x require in terms of resources!

great explanation again.

i inserted y sd card into my machine and windows only recognised it as fat

http://snag.gy/DmBNg.jpg

after downloading specific partition software, i got http://snag.gy/3sKqE.jpg
its just showing fat? how can i tell if its fat 12, 16 or 32?

how can i tell if its fat 12, 16 or 32?

What difference does it make to you?

One thing we can say: with a partition that size, it won’t be FAT12.

im just interested really

how can i tell if its fat 12, 16 or 32?

The third link (FAT) I gave has details of the FAT variants and the MBR entries for each variant – see the summary table on the right.

im just interested really

In a nutshell, the number is the number of bits used to refer to a “cluster”. In Acorn terms, we are used to seeing discs as heads, tracks, and sectors. While this is an anachronism with solid state media, in the old days it directly mapped to floppy disc hardware, and to early harddiscs. Under the FAT filesystem, a “cluster” is a group of (usually) contiguous sectors. This permits the filesystem addressing to refer to objects larger than the native sector size.

Aaaanyway, to elaborate ‘cos I’m bored and it is too damn cold to go fry chicken nuggets:

• FAT8 (8 bit) is from the late ’70s and worked with 8 inch floppies. Nobody remembers this any more.

• FAT12 (12 bit) is from the early ’80s and uses 12 bits to refer to the cluster number, which means 1<<12 possible clusters (minus a few for special/reserved values) and you get a filesystem that is only really suitable for drives less than 20MiB. In fact, the first version of FAT12 used a 16 bit sector count to specify the size of the drive, so it maxed out at 16MiB. I remember being excited when I got hold of DOS 3.3 because it bumped this up to 32MiB so I could finally reformat that ST506 drive in my mess-o-wires XT to use all of the space available. ;-)
  A problem with early FAT was that it used the first track for all of the format/housekeeping, so if track zero was damaged, the disc was entirely useless.
  FAT12 is still kicking around today. Look at any DOS format floppy disc. The maths is interesting. Being 12 bits, two entries (2×12) fit into three bytes (3×8); but, then, anybody who has used FAT floppies will already know that it was hardly designed for speed. ;-)

• FAT16 (16 bit). As above, but expanded in the mid ‘80s to provide a file table using 1<<16 bits to store up to 64K clusters; providing a filesystem suitable for 16MB to 2GB devices. Small FAT partitions and smaller FAT devices (such as 256MB MP3 players, etc) are probably FAT16 although most people call this “FAT” (to differentiate from FAT32 (FAT12 isn’t even an issue!)).

• VFAT. Not really relevant to us, Windows95 introduced VFAT which was basically FAT16 with better management systems in the OS. At disc level, it looks and feels like FAT16 except for the long-filenames stuff.

• FAT32 (28 bit). As drive sizes increased rapidly in the mid ‘90s, it became clear that FAT16 was inadequate. We in the world of RISC OS suffered a similar fate, with old (RISC OS 3.1x) versions of FileCore and drive formats being limited to 512MB. Some companies (Morley SCSIFS, Simtec IDEFS) worked around this by allowing larger drives to be formatted as a number of partitions. Likewise in the PC world, Microsoft took their VFAT idea and modified it for more modern devices. The upper four bits of the 32 bit FAT are reserved, so in reality it offers 1<<28 bits for the file table addressing. Additionally, the largest single file size is 4GB, which while it may be suitable for many, video files can easily exceed this size – not just ripped VOBs, but digital PVRs which record at a fairly high bitrate.
  Any FAT device larger than 2GB is going to be FAT32, which can support – in theory – up to 4TB, however due to the “table” part of FAT, on really big drives you are trading off cluster size for FAT size. On a 64GB drive, using 32KB clusters, your FAT will consume 8MB. The problem here is that every single file would consume a cluster. All those copies of “COPYING.TXT” in GPL projects? 32KB apiece. Because that’s the smallest individual unit within the format; with a standard install of an operating system (a large number of fairly small files) you could experience over a third of your disc’s capacity being wasted due to inaccessible slack space.
  Oh, and your table will be 128MB for a 1TB drive, so wave goodbye to any useful onboard data caching.
  In essence, FAT sucks for big drives, but we still use it because it is simple, compatible, fairly resource light (on the host system – NTFS requires big in-memory data structures), and amazingly everybody mostly agrees on what a FAT drive should be. The alternatives are formats such as NTFS (Windows realm) or ext3 (Linux realm), etc. However as far as I know, RISC OS doesn’t speak any of those and Windows only speaks one. ;-)

• FATX16/FATX32 – based upon FAT16/FAT32 but mucked around with for the XBox. You can’t extract an XBox harddisc and mount it in a PC (unless you have some sort of special driver). We can ignore this one. ;-)

• exFAT – In the mid ‘00s, Microsoft designed a newer better system based upon FAT but different enough that it can become a patent quagmire. It might have attributes, and Microsoft indeed even try to ram it down your throat (Windows 7 format choices as exFAT and NTFS; you need to run the command line format tool if you want regular FAT); however since it needs to be licenced and since it is heavily patent encumbered, it cannot be a natural part of open source operating systems and well… you’ve probably [never|barely] heard if it because of this. OSX supports it, and there is a driver for Linux (but not a kernel driver, now can there ever be). Some devices support exFAT. The majority, I suspect, would just stick to regular FAT32. Certainly, I’ve never seen anything formatted exFAT…

Windows 7

Ah, that would be the OS version they ceased retail sale of recently. Clearly an MS drive to get people to use ext4 filing systems and an OS that uses them :-)

NB. I could have sworn all that FAT information was in the main link or sub-links from it.

Ah, that would be the OS version they ceased retail sale of recently.

They didn’t. They changed the end date back to ‘to be determined’. On the same day even, if I remember correctly.