Partition Manager

Noted, I’ve grabbed your logs

Cool, logs deleted.

@David Pitt, be aware your PartMan pen’s GPT is corrupt. It’s reporting:

GUID partition table entries: 7

Clearly it should only have 2 FileCore partitions. What does PartMan report for the drive?

The device reservation system is described on pages 56 – 59 of the manual I pointed you to. You know what the access key is, because you’ll have set it when you reserve the device.

This only works if I force claim the drives as the filesystems have claimed them all. This is obviously bad as it means any open files are going to be closed and apps start crashing when they read from SCSI drives. It’s needed for write actions, such as initialised, for non-destructive reads however I need to stick with the MAGIC_ACCESS_KEY.

SCSI_Op should really check if the action is a read and allow it – not just assume all SCSI_Op are destructive. I’ve not looked at the code to confirm exactly what it’s doing.

Screenshot from PartMgr 0.39 doesn’t show the FAT partition.

That is correct, it shouldn’t show a FAT partition and should be a full disc FileCore. I put a check in for “Castle” in the Boot Code, as that particular formatter doesn’t create a valid MBR table.

SCSI_Op should really check if the action is a read and allow it – not just assume all SCSI_Op are destructive.

Try it with a null key.

The Morley document (I linked to earlier) implies that the access key is only checked for potentially destructive operations (in which case you’d want the device dismounted anyway).

@David Pitt, be aware your PartMan pen’s GPT is corrupt. It’s reporting:

GUID partition table entries: 7

Clearly it should only have 2 FileCore partitions. What does PartMan report for the drive?

*listpartitions 1

Found 2 disc partitions
SCSI ID:01 Start 00000004 Size 07397ffb SCSIFSdisc 1
SCSI ID:01 Start 07397fff Size 07398000 SCSIFSdisc 1
*

Hmm!!

v0.43 up. Hopefully it resolves the three issues below:

@Doug Webb, does it now identify both of your IDE drives on the Iyonix?

@Alan Adams, do both SD’s show down the bottom?

@David Pitt, does it report Filecore1 and Filecore2 correctly?

Regards your PartMan pen:

Address :        0        4        8        C
&000000 : 20494645 54524150 00010000 0000005C   EFI PART....\...
&000010 : 3D56467B 00000000 00000001 00000000   .FV=............
&000020 : 0E72FFFE 00000000 00000004 00000000   ..r.............
&000030 : 0E72FFFB 00000000 8150F003 D5B37029   ..r.......P.)p..
&000040 : 5647A0B0 B0A04756 00000002 00000000   ..GVVG..........
&000050 : 00000007 00000080 7D415438 00000000   ........8TA.....

@David Pitt, does it report Filecore1 and Filecore2 correctly?

No, both partitions now report as FileCore!.

The PartMan source doesn’t make a lot of sense,

We don’t really know the status of the PartMan partitioning tool. It appears to result in working partitions but is perhaps not quite perfectly formed at closer inspection. It is probably best to defer this until later for now.

@Alan Adams, do both SD’s show down the bottom?

Yes, both shown correctly.

I also tried with the FAT32 disc unmounted and mounted – the name was not displayed in either case. You probably knew that.

Please excuse my ignorance, but why does each of your updates, referenced as PartMan0.xx.zip or whatever, download as “file” with a type data. OK, they’re zip files and can be dragged to SparkFS to be typed, but why?

If I do this on my site it just works!

Many will not know about the “drag to SparkFS” bit, and so won’t participate!

No, both partitions now report as FileCore!.

I think it’s getting the logical disk then, not the physical, which would explain all the other issues.

It is probably best to defer this until later for now.

I put PartMan out of scope before I even started coding, but figured I might as well have a go at it whilst bug fixing other issues.

why does each of your updates, referenced as PartMan0.xx.zip or whatever, download as “file” with a type data

I don’t know, either you’re missing the mime type, or the browser can’t cope with modern standards? Which browser are you using?

Line 130 in gpttest looks a bit suspect:

result=PartitionDisc(ID, MaxPartitions, partcount, partn);

Should that not be:

result=PartitionDisc(ID, partcount, partcount, partn);

It would explain why David’s drive created via gpttest has 7 partitions.

don’t know, either you’re missing the mime type, or the browser can’t cope with modern standards? Which browser are you using?

I suspect that John’s answer is Netsurf. It certainly is in my case.

but why does each of your updates, referenced as PartMan0.xx.zip or whatever, download as “file” with a type data

I suspect that you and I have something wrong wiith our configuation of file Mime types, but I do not know what. The problem is with our Netsurf configurations on RO 5.28 because the file downloads correctly when I use Firefox on a PC.

Perhaps some kind soul will tell us what we have wrong and maybe even how to put it right.

In the meantime we can carry on dragging the file to SparkFS or manually setting the file type of the downloaded file to “Zip”

Jon,

One minor detail which has been present since V0.?? is that in the text descriptions at the bottom of the main Window, the layout text E+, Boot, Big ma| does not quite fit in the field width. I am using RO5.28 on a Pi4.
Line 820 could be    partition_columns%(C_volume%,1)=480-15
with line 840 being   partition_columns%(C_layout%,1)=200+15

Otherwise v0.43 is looking good to me.

Perhaps some kind soul will tell us what we have wrong and maybe even how to put it right.

I’m going to suggest “not much”.

steve@ullscarf:~$ wget -S <a href="https://forums.jaspp.org.uk/forum/download/file.php?id=388">https://forums.jaspp.org.uk/forum/download/file.php?id=388</a>
--2021-01-24 23:37:13--  <a href="https://forums.jaspp.org.uk/forum/download/file.php?id=388">https://forums.jaspp.org.uk/forum/download/file.php?id=388</a>
Resolving forums.jaspp.org.uk (forums.jaspp.org.uk)... 109.156.19.89
Connecting to forums.jaspp.org.uk (forums.jaspp.org.uk)|109.156.19.89|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sun, 24 Jan 2021 23:37:13 GMT
  Server: Apache/2.4.38 (Raspbian)
  Set-Cookie: phpbb3_pw5ls_u=1; expires=Mon, 24-Jan-2022 23:37:14 GMT; path=/; domain=forums.jaspp.org.uk; secure; HttpOnly
  Set-Cookie: phpbb3_pw5ls_k=; expires=Mon, 24-Jan-2022 23:37:14 GMT; path=/; domain=forums.jaspp.org.uk; secure; HttpOnly
  Set-Cookie: phpbb3_pw5ls_sid=3bff666cdaa6ca6307b1d3bbcb079e0f; expires=Mon, 24-Jan-2022 23:37:14 GMT; path=/; domain=forums.jaspp.org.uk; secure; HttpOnly
  Cache-Control: private
  Content-Disposition: attachment; filename*=UTF-8''partmgr043.zip
  Last-Modified: Sun, 24 Jan 2021 18:05:18 GMT
  Content-Length: 40050
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: application/octet-stream
Length: 40050 (39K) [application/octet-stream]
Saving to: ‘file.php?id=388’

file.php?id=388                  100%[==========================================================>]  39.11K  --.-KB/s    in 0.03s   

2021-01-24 23:37:14 (1.29 MB/s) - ‘file.php?id=388’ saved [40050/40050]

steve@ullscarf:~$

The server is saying that the file is “application/octet-stream”, which is data; were it typed for a Zip file, it would be “application/zip”.

Setting the type as “application/octet-stream” isn’t wrong, but it doesn’t help browsers which don’t then look at the filename extension and make a guess as to what the type might be.

ETA: It’s complicated because the actual filename is buried in the ContentDisposition header, and differs from the one in the URL. That’s another layer for the browser to decode.

filename*=UTF-8''partmgr043.zip

That looks a bit odd! It may be valid, but it’s certainly weird.

Edit: It seems that it’s part of RFC 5987. I’m guessing that NetSurf doesn’t know how to handle this.

Edit: It seems that it’s part of RFC 5987. I’m guessing that NetSurf doesn’t know how to handle this.

That bit certainly seems to be the answer to the question “What do we have wrong”

@John Williams
It looks like we just keep on dragging the file to SparkFS

Have try 0.43 on Titanium. The debugfiles you find here.

First try: Old EADFS device on SCSI. Two things together ;-)
Anton has made a quick fix for partman, so the old EADFS partitions are known…

*listpartitions 0
Found 4 disc partitions
SCSI ID:00 Start 00000000 Size 000ffb10 SCSIFSdisc 4
SCSI ID:00 Start 000ffb10 Size 000ff720 SCSIFSdisc 5
SCSI ID:00 Start 001ff230 Size 000ff720 SCSIFSdisc 6
SCSI ID:00 Start 002fe950 Size 0010b02f SCSIFSdisc 7

He send me an “sector 0” screenshot. Short view, looks like is comparable to the debug file…

Maybe it helps for later things.

PartMgr ignores all partitions but the first is usable without any additional Tools.

Next try: GTP and 1TB (ADFS/FAT)…
1TB: *listpartitions 0

Found 2 disc partitions
SCSI ID:00 Start 00000000 Size 1d1d0000 SCSIFSdisc -1
SCSI ID:00 Start 1d1d0000 Size 57536daf SCSIFSdisc -1

GPT:*listpartitions 0

Found 2 disc partitions
SCSI ID:00 Start 00000004 Size 1d1c3013 SCSIFSdisc 4
SCSI ID:00 Start 1d1c3017 Size 1d1c3018 SCSIFSdisc 5

GPT is detected but without partition names Try on SATA and SCSI.

1TB: The second FAT partition is ignored. Also SATA and SCSI.

result=PartitionDisc(ID, partcount, partcount, partn);

It would explain why David’s drive created via gpttest has 7 partitions.

That worked, PartMgr 0.43 only displays the two filecore partions, the spurious extras have gone.

v 0.43 First, just to confirm, from my MBR partitioned disc with

*partiFC SCSIFS :4 -v
Disc size total:         465.8 GiB
512 Byte/Sector
Primary partitions:
 B Start    Sectors       Size      Typ
   00000001 1fffffff     256.0 GiB  ad  ADFS
   20000000 1a386000     209.8 GiB  0c  FAT32 LBA

The PartMan source doesn’t make a lot of sense, it calls GUIDValid for each GUID, but it doesn’t appear to do anything other than copy the value. I can’t see how it decides if a GUID is valid and should map a SCSI ID (LUN I hope?) to it.

My addition in PartMan to recognice MBR partition is in CheckGTPValid().
If suitable partitions are found I fill

gpth->GUIDPnum
gpth->FirstOKLBA[0]
gpth->LastOKLBA[0]

myGP->PTypeGUID  =GUID_Filecore
myGP->StartLBA[0]
myGP->EndLBA[0]

One minor detail which has been present since V0.?? is that in the text descriptions at the bottom of the main Window, the layout text E+, Boot, Big ma| does not quite fit in the field width.

If you read the notes just about the download link, it does state you can’t currently change the column widths.

@Raik, your EADFS device – I have no idea what that Sector 0 is, it’s neither an MBR or a GPT table. Is EADFS another filesystem?

GPT is detected but without partition names Try on SATA and SCSI.

I’m not sure if it was you or someone else, but the GUID on the GPT drive (ADFS::7 in your 2nd pic) doesn’t have the correct GUID. If it’s a test drive created with gpttest, download the source, apply my gpttest bugfix then recompile and try recreating the drive again.

Your GUID is: 656C6946-6F63-6572-5479-706553303031 but it should be 656C6946-6F63-6572-5479-706530303031

My addition in PartMan to recognise MBR partition is in CheckGTPValid().
If suitable partitions are found I fill

I guess it ignores the MBR partition table as its implementing GPT in preference and as it was developed for a commercial product, there was no requirement for MBR support.

Your GUID is: 656C6946-6F63-6572-5479-706553303031 but it should be 656C6946-6F63-6572-5479-706530303031

On the point of FileCore partition detection, my code is using OS_FSControl 55 to check if a drive is FileCore, so it’s only going to detect drives that are actually accessible.

I’ve yet to figure out how PartMan is handling partitions, but as I’m using OS_FSControl 49/55 to detect a FileCore drive, I need to link a partition to a SCSI::x before it can be recognised as a FileCore partition. I probably need to completely rethink how FileCore is detected and reimplement OS_FSControl 55/49 so its independent of the OS.

EDIT: I’ve cross checked my code against the documentation for SCSIFS_Partitions and provided partitions are mapped to LUNs, which are mapped to SCSI::x drives, Partition Manager should detect them and link SCSI::x to a physical drive and partition.

@Raik, your EADFS device – I have no idea what that Sector 0 is, it’s neither an MBR or a GPT table. Is EADFS another filesystem?

Not sure about. EADFS = Enhanched ADFS (?). Was from Powertec and allowed to use larger IDE devices on RISC OS 3.1 plugged to the standard IDE port. I use the HDD in my A4 Laptop round about since 1994 (The A4 is gone with a lot of smoke 2011 :-(). The 2GB are splitted with PowerIDE to 4x 512 partitions. The first partition was/is normal readable without any additional tools as ADFS.

Sector 0: Is a question to Anton ;-) As I understand you find the offset and a size of the partitions in it.
Detail… Anton please ;-)

EADFS = Enhanched ADFS (?). Was from Powertec and allowed to use larger IDE devices on RISC OS 3.1

Ah, that explains the odd sector 0 then. It will have been using IDEFS, so I’ll make a note of it.

I don’t think anyone has noticed my glaring mistake. In the physical drives section (left of top section) its listing drives as ADFS::4 / SDFS::4 / SCSI::0 etc.

This is complete nonsense, as those are OS drive references. So, how should we refer to physical drives where partitions will be mapping to ADFS::4 etc?

ADFS / SDFS / SCSI are the correct filesystems, but we can’t use ::0 / ::1 and need some other means of specifying the physical drive. For SCSI we can use the ID without the LUN (eg SCSI:0:1), I’m not sure about ADFS, SDFS et al.

EDIT: I suppose ADFS could also use ADFS:0:0 / ADFS:0:1 for Master/Slave on the Primary IDE controller and ADFS:1:0 / ADFS:1:1 on the Secondary

I don’t think anyone has noticed my glaring mistake. In the physical drives section (left of top section) its listing drives as ADFS::4 / SDFS::4 / SCSI::0 etc.

Well, perhaps, not too many people.

Posted on 15th January:

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.