FAT32FS Bug?

Hi,

Could someone test the following for me – I think it’s a bug but would be helpful to confirm.

Inserted USB stick into Pandaboard, with FAT formatted disc. Panda ROM is 3 days old.

Saved a data file (256 bytes) with NO FILE EXTENSION.

Inserted into Pi (7/12/13 ROM).

Any attempt to open the file results in the machine stiffing. Other files are OK.

Opened the file on my Mac – fine.

Filename is shown as dataed~1 on Finder on the Mac.

Added a file extension to it to become dataedid.txt, reinserted into Pi – file opens fine.

Saving a file onto a FAT formatted USB stick under RISC OS can result in the file being stored as a CAPITALS only 8.3 form filename or as an ‘extended’ non-8.3 capitals-only filename. It can also result in the two FAT (file allocation tables) becoming inconsistent. The results can be different depending whether you use SCSIfs or FAT32fs. Don’t write to a large pen drive (more than 2Gbytes) using SCSIfs – that is not supported and will always fail.

Saving a file onto a FAT formatted USB stick under RISC OS can result in the file being stored as a CAPITALS only 8.3 form filename or as an ‘extended’ non-8.3 capitals-only filename.

Blame software patents in the US.
If the code has its origins in the Linux world, this behaviour is wrong but by intention. Sad but true.

More info at this topic: https://www.riscosopen.org/forum/forums/5/topics/2211

Don’t write to a large pen drive (more than 2Gbytes) using SCSIfs – that is not supported and will always fail.

I thought that has always been a ‘given’ if the stick is formatted FAT rather than filecore.

I thought that has always been a ‘given’ if the stick is formatted FAT rather than filecore.

DOSFS supports both 4GB images (since 1.00, Jan 2013) and FAT32 (since 0.79, Sep 2004) contrary to most frequently uttered misremembering. Both are fully supported, neither should fail.

Prior to that 2GB and FAT16 were the limitations for the respective versions (0.99, 0.78).

My experience with a 4GB SDHC card seems to refute Sprow’s post, although this thread is about sticks rather than cards. The card is a partitioned one for a Raspberry-Pi. When inserted in a card reader on my PandaBoard, Panda freezes when I attempt to copy or open a file, or even do a ‘count’ on a file, in the FAT32FS bootloaders partition of the card.
This partition is 48MB in size, the ‘RISC OS’ partition is 1827MB in size and so combined they amount to just under 2GB.
I can’t look at the partitions on any of my Raspberry-Pis as, at the moment, none of them will boot with this card — don’t know why, as the card used to work.
This is repeatable with another 4GB Raspberry-Pi card which does work with my Raspberry-Pi’s.
The files and directories in the ‘bootloaders’ partition of the first card (haven’t tried the second card) can be opened on my son’s Apple laptop, corroborating William Harden’s test.

Sprow:

DOSFS supports both 4GB images (since 1.00, Jan 2013)

The problem is, DOSFS (prior to that date) happily trashed a 4GB FAT device without so much as giving a warning . I posted on this at the time saying that if DOSFS is unable to cope – why doesn’t it reject the device and refuse to mount it? What will happen now if I inserted an 8GB device? Will it be mounted or will DOSFS complain?
I use FAT32FS because, well, I don’t much trust DOSFS for the reason stated above.

David:

in the FAT32FS bootloaders partition of the card.

FAT32FS != DOSFS (which is not FAT ;-) ).

I can’t look at the partitions on any of my Raspberry-Pis as

Do you have DiscKnight? If so (or if not, download the check-only version) try checking the media. You can either use a USB SD reader, or you can dismount the SD card you booted from and swap in another.

don’t know why, as the card used to work.

Did you change the ROM image?
Are you using the correct firmware?

For the current ROM images (inc. my own builds), the firmware is:

BOOTCODE.BIN   - 17,824 bytes
FIXUP.DAT      - 5,758 bytes
START.ELF      - 2,488,796 bytes

none of them will boot with this card

What actually happens at boot failure? When my SD card’s filesystem corrupted, I was able to get as far as the pretty screen. It then aborted with really tiny text telling me the maps were all screwy. Do you get that far?
If not, do you get as far as the keyboard LEDs coming on?
If not, do you get as far as seeing any activity on the SD card indicator? [green ACT, it’ll be brief so watch carefully!]

If the answer to all of the above is no, try checking the FAT part is correct (chkdsk, dosfsck, etc according to OS).
Then rename the ROM image and place a known-good copy there (in case it got damaged).
Verify your firmware matches the ROM image (if in doubt, use a recent one and current firmware).

Does this get you any further?

@Rick

I have done a DiscKnight check and repair, but still I can’t open, count or copy any of the files in the bootloader partition.

I haven’t changed the ROM image or firmware for some time – card used to work. I can’t compare the exact sizes of the files with the 3 given in your post as any attempt to do a count results in a freeze, but in the filer window I have 17k for Bootcode/bin, 5k for Fixup/dat and 2297k for Start/elf. There are also other files and directories there apart from Riscos/img and LICENCE/BROADCOM: Config/txt, Fixup_cd/dat, Backup1, Backup2 and some objects (Trashes, /fseventsd /_/Trashes) deposited on the card when it was examined in my Son’s Apple laptop. I can’t, of course delete any of this ‘trash’!

When I attempt to boot with the card, there is nothing on the screen and, apart from the red PWR light coming on, only the ACT green light flickers briefly and sometimes continues to pulse about 6 rapid on and offs followed by a small gap and then this pattern repeated.
All the bootloader files, not the ROM image, are dated 2/11/2012 including the licence.

Where can I get chkdsk and dosfsck? I thought I had them somehwere, but can’t find them and they aren’t on Packman or Store.

SystemDisc says that the card is a valid system disc.

@ David:

Where can I get chkdsk and dosfsck?

Windows (chkdsk) or Linux (dosfsck, maybe…). The latter is a better option.
Isn’t MACOSX a sort of Linux with a custom kernel? Maybe that has some sort of tool to check FAT media?

@Rick

I thought I saw chkdsk as a RISC OS binary somewhere. Neither chkdsk nor dosfsck are recognised as commands on my EeePC running a version of Linux. Anyhow, I could open config/txt, look at the size of the files in ‘properties’ and copy the files to a USB stick. The sizes are: bootcode/bin 17,764 , fixup/dat 5,280 and start/elf 2,352,536.
It looks as if the failure to read these files from the SD card on RISC OS is a failing in RISC OS rather than faults on the SD card.

Isn’t MACOSX a sort of Linux with a custom kernel?

A version of X

Neither chkdsk nor dosfsck are recognised as commands on my EeePC running a version of Linux.

Try fsck, that will exist. dosfsck is a variant for a specific filesystem, sudo dosfsck should fail and offer to try and download/install it for you.

OK I have done an fsck on the SD card with the following result.

/home/user> sudo fsck /dev/sdc1
fsck 1.40-WIP (14-Nov-2006)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Reserved field in VFAT long filename slot is not 0 (but 0xe5).
1: Fix.
2: Leave it.
?

So, do I fix it?

I also did another fsck on the same card but with a different address with a different result.

/home/user> sudo fsck /home/user/D:/
fsck 1.40-WIP (14-Nov-2006)
e2fsck 1.40-WIP (14-Nov-2006)
fsck.ext2: Is a directory while trying to open /home/user/D:/

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

/home/user>

So what’s a superblock?

fsck.ext2: Is a directory while trying to open /home/user/D:/

When you want to examine a file system, it is best to give a direct device reference ( /dev/something ). Otherwise the system will likely conclude that the symlink is part of a ext filesystem (your native filesystem appears to be ext2) and then fail because the symlink looks like a directory (which is correct), not a device.

Or in non computer terms:
/dev/something = stand in the garden and look at the house
/home/user/something = go through the front door, then go up the stairs, then look at the house (logic fail!)

PS: if I remember correctly, the “superblock” is some metadata that describes the filesystem. I think it is sort of equivalent to FileCore’s “boot block”.