Partition Manager

v0.27 up, with a few bug fixes.

I’m now going to make a start on the debug output, so I can resolve the outstanding issues reported above.

Hi Jon,

I have just tried your v0.27 on a Pi4 with a 16GB SD card with a single 4GB FAT32 partition – written by Win32DiscImager.

Partition Manager correctly shows 4 (3.65) GB Partition as FAT32 but with only 58 MB free. The card only has the minimum 5 files needed for a Pi 4 boot. (*free shows 3.9 GB free)

The rest of the SD card is correctly shown as unallocated.

Partition Manager correctly shows 4 (3.65) GB Partition as FAT32 but with only 58 MB free

Partition Manager and *Free work in different ways.

With FAT12/16 you have to trawl the whole FAT and sum up the free space. With FAT32 Microsoft introduced a free space value into the FAT header – its this value that PM reports. Microsoft however failed to make it mandatory for software to update the free space value. In theory, if you write something to the disk via either DOSFS or a PC, it should update the free space and then report correctly.

If it’s not that, it’s a rounding error which we’ll figure out once I get the debug output coded.

EDIT: Although the above is true, its not accounting for the cluster size in the FAT partition

v0.28 up with minor tweaks to ADFS and FAT.

take 4096 byte sector size into account

I’ve added recognition of ADFS hosted drives that support multi logical sectors per physical. I don’t think ADFS knows about them though, which might lead to some issues. I do not have a suitable drive to test it.

Partition Manager correctly shows 4 (3.65) GB Partition as FAT32 but with only 58 MB free

This is hopefully fixed, I’d failed to account for the cluster size.

This is hopefully fixed.

Looks good to me :)

Another minor issue is that in the text lines the mSATA drive shows as (SCSI::4) but the SDcard shows as (SDFS::0.$.?)

Which prompts me to ask:
In the graphical presentation, should the mSATA drive be described as ‘Disc 0’ rather than SCSI::4
and then the designation SDSI::4 be listed in the partition graphic along with the drive name.

(SDFS::0.$.?)

That’s placeholder text to show the DOSFS filename that wraps an embedded FAT partition within a FileCore drive. I’ve yet to look at how to handle them and it doesn’t current make any attempt to check if a FAT partition is actually embedded or has an accompanying DOSFS file.

Just ignore it for the time being.

to check if a FAT partition is actually embedded or has an accompanying DOSFS file.

If the FAT partition is physically first then it will be embedded as any filecore partition starts at a fixed sector address (just after the partition table itself) by definition. Whether the FAT partition exactly aligns with a DOS image file in the filecore partition (and thus discover its name) might be tricky to check…

If the FAT partition is physically first then it will be embedded as any filecore partition starts at a fixed sector address (just after the partition table itself) by definition

Currently that’s the case for some systems, although it may change when partition support is added. As is evident from some of the reports above, some systems do not have a partition table, but do have a FAT area embedded in the FileCore area, which I need to cover.

Once partitions are implemented, FileCore will no longer start at LBA 0 and its unlikely we’ll retain embedded FAT partitions. FileCore however will still support embedded FAT via DOSFS unless its deprecated.

Having the FAT embedded in the Filecore partition obviously has advantages, as it allows access to update RISCOS etc via PackMan and modify the Pi blob config from within RISCOS. How this is going to be handled once partitions are implemented I don’t know. My view is that DOSFS needs extending as part of the partition bounty to handle FAT partitions, or FAT32FS needs to become part of the OS and mount FAT partitions.

FileCore however will still support embedded FAT via DOSFS unless its deprecated.

Deprecated or not, it’ll still have to support it, given that the majority of Pi machines, and likely a significant number of other devices, have their SD cards set up in exactly that manner.

I have just had a look at v0.29 and have the following comments which I hope are helpfull.

1. mSATA drive information all looks good.

2. USB memory with 4GB MBR FAT32 partition is recognised as existing (SCSI::0 3.72GB) but with total space unallocated 3.72GB).

3. 4GB SD card with 3.69 GB Fat 32 MBR Partition is shown in graphic as {unknown} of 3.65 GB. and the text line also says {unknown}

v0.29 looks good.

v0.15 worked with my FAT/EXT4 formatted USB SDD plugged in, whereas v0.29 still requires an unplug of the SSD drive for it to work. You have already mentioned this may see a fix in the debug version. ;)

Parameters not recognised in “add_drives_SCSIFS” at line 88"

v0.30 now up, with debug output. If people that have issues could upload !PartMgr.debug/txt with a description of what the issue is, I can investigate.

The file can get rather large, so you might want to register on the JASPP forum, where you can attach files and pictures etc. Accompanying screenshots/photos of Partition Manager would also help.

Thanks Jon.

v0.30 looks good.

Thanks for the update. I have a debug text file. I have tried the forum, but I’ve ip banned and now it doesn’t appear to remember my username. Perhaps that’s a result of trying to create an account using !NetSurf and then switching to Firefox on Raspbian. Are you on ChatCube?

ip banned

Sorry about that, over the past 10 years the site has built up a ban list of over 1000 IP ranges, which I’ve just cleared down. You haven’t actually created an account as it was blocked, so please try again and I’ll approve the account.

Avoid NetSurf on the site, it needs to go the same was as HForm! We’re stuck with Textile due to that browsers lack of modern standards.

Thanks, just tried again and I’m getting the following message.

No soup for you! It looks like you have been flagged as a spammer.

I like NetSurf, its what we have! As you know, sadly, a fast, modern browser is out of reach for the community as a whole, but I’m hopeful that will change at some point.

No soup for you! It looks like you have been flagged as a spammer.

It’s reporting your email is a known spam address on Stop Forum Spam so you’re out of luck. You’ll have to post it on here I’m afraid, or raise a removal request to get off the list.

I’m not on their list as a spammer; neither is my IP address.

I’m not on their list as a spammer; neither is my IP address.

It will be the combination of your username and/or IP/gmail address. The IP is on a list of Virgin spam addresses and your username is fairly generic so the combination is raising your risk level.

If you don’t want to post on here, I’d try registering using a different username. Search for your chosen username on SFS to ensure it’s not listed first.

Getting back on topic, I’m going to make a start on formatting full disc FileCore, which will replace HForm in its current form.

Log deleted.

Partition 1
-————
Partition_Type%=&C
Start LBA =&0E8D84000
Size in LBA =&000084800
Checking SCSI::4 partition 1 for FAT
read_bytes_SCSIFS(1,&E8D84000,&0,..,&200)
SCSIFS_DiscOp64 drive=4 LBA high=&1D1 LBA low=&B0800000

SCSIFS_DiscOp64 is failing when trying to read Partition 1. The command looks okay to me, LBA &E8D84000 is below the disc limit of &E8E088AF so there’s no reason for it to fail.

If you plug it into a PC, can you access that partition? It appears to be 265MB FAT32 from the partition table entry.

Could you also try the following from BASIC to confirm the error:

!&10000=4
!&10004=&B0800000
!&10008=&1D1
SYS "SCSIFS_DiscOp64",,1,&10000,&10100,&200

Sounds suspiciously like an issue with SCSIFS to me. Is it performing a limit check based on the FileCore size of the drive? I’ll recreate your drive and see if I see the same issue.

Could you also try the following from BASIC to confirm the error:

It reports “Line too long”

The drive works not matter what I plug it into, it was formatted and partitioned under Linux. It has a FAT32 and an EXT4 partition. It worked under v.015 of !PartMgr. I use the FAT partition to share files between systems RISC OS and Linux. So I only use it when needed under RISC OS, but under Linux it is used all the time. At the desktop now its labelled 4, but when I click on it, that changes to Transfer.

Hi Jon,

I have run 0.30 on my ARMX6 and Iyonix and posted the screenshots and debug code on JASPP for the missing SDFS::1 and mismatch sizes.

@Jon

My Titanium PartMgr 0.30 results are here.