Fay32fs

Fat32fs 1.42 (12 Jan 2013) seems to have a bug. I have noticed problems when writing a file – the writes proceed without error but only part of the file actually appears. This is on Pandaboard ES with a fat partition on the SD card mounted using

fat32fs:dismount :16 { > null: }
fat32fs:mount -fp2 :16 { > null: }
addtinydir fat32fs::16

The problem is intermittent and I can’t seem now to persuade it to reappear..

Under what circumstances is this happening? Are you moving the SD card between machines?

I am not moving the card between machines. I have formatted the unused part of the SD card (i.e. above the 2G dual partition) as FAT and use it for data and lots of stuff. It is working again now but the problem was noticed when using BPUT#T,“string” to write a large file – it appeared to work, with no errors, but the file was incomplete, once with garbage at the end. Running the same programme on the SD card (SDFS::0) and the file was created correctly. I was also getting an odd error when trying to edit the file I had created (under fat32fs) – Zap said ‘version on disc is newer’ although nothing else was loaded.

Today I can’t replicate the problem.

On an ARMini (BB version) I have certainly had random problems when writing large files to a 128GB Fat32 formatted SSD, although in my case the filer sometimes throws up an error, at other times the transfer/save just stops and a reset or reboot is the most reliable way to recover.

I have no idea whether the root cause is Fat32Fs, or the usb-scsi stack or hardware.

It does happen with more that one SSD, which are always connected via an external powered hub (more than one type has been used). (I have never had much success trying to run hard drives on the ARMini internal hub as supplied).

I also have some external (usb) Seagate rotating drives, 300GB, self-powered which I bought cheap at Maplin a few years back, and these have never given any trouble. Thus up to now I have put my problems down to hardware rather than software.

I am not using the USB system – just fat32fs over SD Card, so that seems to implicate fat32fs rather than the USB stack…

I have similar problems.
Fat32FS: With some (not all) USB Flash Drives, if I write data the filer does not show any error message and apparently the files were copied. Dismount / Mount … Directory / files are no longer visible in the filer.

SSD: With the ROMs prior to May 2012 (?), I had no problems. After that it was so, that when copying from HD to SSD, the SSD take in the standby mode while the HD is still reading. The filer aborts because RISC OS does not wake up the SSD again.
Using the mouse and click Retry ind the error message window it goes on until the next deep sleep :-(
3 out of 4 of my USB to SATA adapters that is. A slightly older works … might not yet know the power saving mode.

After that it was so, that when copying from HD to SSD, the SSD take in the standby mode while the HD is still reading. The filer aborts because RISC OS does not wake up the SSD again.

I do not use flash drives very much, and haven’t noticed any problems with them. However, I do get somewhat similar problems with SSDs (I have five 120 GB ones in total, not all the same make) and use them on BB and RPi. I always thought it was related to the usb hardware, perhaps lack of speed, because they all seem fine when connected to the Iyonix.

Edit: I should add they are all Fat32 formatted.

Sorry, the “wake up problem” is a 60GB ADFS SSD. I have also a 60GB Fat32 one and here I have more the “no copy but it looks like” error.
With the older 5.17 ROMs I can not remember on any problems.
I have also not this problems with my a9home (only adfs) but it works slow, very slow… USB1.1 ;-)

I am not using the USB system – just fat32fs over SD Card, so that seems to implicate fat32fs rather than the USB stack…

The SD card has a driver. That’s where my suspicion lies.

I did a lot of work figuring out how to drive SD cards. The first problem is that access to the full standards costs a lot of money, so we have to work from documentation of severely limited content.

I’ve never had quite 100% confidence in the status codes returned by the SD interface. There have been instances where my software was used to write cards, but some writes failed. Internally, the status said it was OK, but some of the card was unreadable after.

Maybe thats the reason why the most SoC-boards have a SD-card compatibility list. We are not alone ;-)

Even a compatibility list is of dubious use. The card manufacturers can produce cards that are externally the same but have any number of different internal designs.

I know :-( ;-)
For the Pandora I have a Scandisc Ultra Card 64GB… best in list but never work and a 32GB Transcend that should never work and it is working fine.
For the xM I have two 2GB transcend. Nearly the same serial number. One is working fine, the other it not bootable if I change the ROM via SDFS…
Scandisc, Hama … the same. One is working and the same looking not.
I mean I have a tool for WIN that read the real manufacturer data.

Have just got an error from fat32fs (1.42) which said ‘Wrote 0 bytes of 512’ when trying a BPUT#r%,b% and then gave the same error after *CLOSE. This is on a Pandaboard ES whilst writing to the third partition (FAT) of an SD card (the other partitions are FAT (for firmware) and filecore (for !Boot etc)). Managed to repeat this but then it worked OK from then on.

‘Wrote 0 bytes of 512’

I have seen similar types of message on a BB-xm when copying large files from one Fat drive to another, and occasionally when saving a large file. I have never been sure whether it is Fat32Fs itself, or the underlying OS modules.

I don’t know whether a problem I have is related to the problems with fat32fs in this thread.
I copy a file from my ASUS transformer prime onto a USB stick (fat32 formatted) and then stick the USB stick in my Pandaboard ES to copy the file onto Panda’s SD card. The trouble is that I can’t see the file on the USB stick. :-((
This is a regular problem.
If I stick the USB stick in someone’s Windows computer, the file is seen. If I then copy it to the Hard drive of the Windows computer, rename it and copy it back onto the USB stick, I can see it on my Panda.
I haven’t done any thorough testing of this, so I don’t know whether the renaming is necessary.
The ASUS pad is running Android (Ice-cream) and Panda has fat32fs version 1.42.

You do go through the “Safely remove hardware” process before you unplug the USB stick from Windows every time, don’t you?

I’ve seen a similar problem but it happens in both dosfs and fat32fs. I modify a file on a pc and cut and paste it to a memory stick for transfer to my iyonix. Repeating this process a number of times overwriting the original file when pasting – file getting bigger each time – eventually the file can’t be read on the iyonix (though it can on a pc). Its as though there’s a problem when the file extends. I rename the original file then paste to work around it. Is as though riscos has problems with fragmentation.

They look like two different problems to me, if I’ve understood David Lane’s description correctly. For the file not to be seen at all implies a problem reading the directory. To be unable to access the data, and/or for the file to get bigger each time, implies some problem following the chain in the allocation table.

I always dismount the USB stick whether on my Android Pad or on Windows or even on RISC OS. I didn’t include this information in my post as I thought it a bit boring. ;-)
I, like Colin, wondered whether it was to do with fragmentation of the file on the USB stick, not being understood by RISC OS.
I will check whether the file is getting bigger each time; but perhaps one should expect that on FAT. :-)

I have tested my problem again with a jpg file that came with my Asus transformer pad. I copied it to a FAT32-formatted USB stick, dismounted the stick, stuck it in my Pandaboard, but it can’t be seen by RISC OS.
However, the file can be seen and opened on (my Wife’s) MS Windows laptop. Next, I rename it from Bus.jpg to BusPicture.jpg on the MS laptop. Now it can be seen and opened on Panda. Weird or what?

Is this to do with there being more than one FAT (file allocation table) and that Windows writes to only one of them? That way Windows sees a different set of files to fat32fs?