PFS3AIO v3.1 Final

[Toni Wilen]

Originally Posted by apex

Ok, will try again using number 6. I used latest loadmodule from Aminet. FFS is working, for PFS I will check in the evening.

You still didn't say how exactly it "does not work". How do you confirm it isn't working?

It should work exact same as previous (v1 and v2) PFS3AIO versions.

[apex]

No (more) problems here. Can be loaded with latest loadmodule. Great, thank you.

[kolla]

Been running test #6 without any issues so far on two CD32 systems, one with SX32 Pro and one with TF328. Time permits, I will test with other systems this weekend

[Sandancer]

cool thank you will test it out

[Toni Wilen]

Originally Posted by thomas

The IDEfix package contains a KillDev program which can unmount CD drives mounted with CacheCDFS.

If you can get rid of a PFS partition with this program I would assume it works.

Thanks. And it didn't work (corrupt memory list), ACTION_DIE was replied too early, before volume node and other stuff was released and freed..

[mark_k]

Originally Posted by Toni Wilen

Oops, +1 and zero check (drive too large) got lost when I cleaned up the code It was "blind" assembly to C conversion originally, I didn't write it originally.

What about when the max.LBA in READ CAPACITY data is 0xFFFFFFFF, which will be the case for large (>= 2TB with 512 bytes/sector) drives?

Exactly what to do in that case is arguable. On the one hand, 0xFFFFFFFF + 1 is probably not the actual number of sectors, and anyway that wouldn't fit into the 32-bit dg_TotalSectors field. So maybe it is best to return failure then, falling back to using DosEnvec values.

You could attempt to issue READ CAPACITY (16) to get the real number of sectors, but probably a lot of other calculations are 32-bit so effectively prevent access to the past-2TB (assuming 512 bytes/sector) region.

Another possibility might be to fake a larger sector size; e.g. with fake 4KB sectors, the 32-bit sector# limit is at 16TB.

[Toni Wilen]

It works exact same as original code, FFFFFFFF = too large, rejected.

Not my problem, I didn't design it. Reason for "Don't ask me!".

[Toni Wilen]

PFS3AIO 3.0 Test #7. Unmount fix.

[TuKo]

Hi Toni,

Is a format needed every time a new update comes out or is it enough to update FS in HDToolBox ?

Thanks in advance

[malko]

Originally Posted by TuKo

Hi Toni,

Is a format needed every time a new update comes out or is it enough to update FS in HDToolBox ?

Thanks in advance

Ses reply #14 in this thread

[TuKo]

Originally Posted by malko

Ses reply #14 in this thread

thx !

[malko]

Don't mention it

[TuKo]

I get a guru with experimental version of pfsdoctor on large partition (>26GB) with lot of files with test #7. Works ok with original pfsdoctor.

[Toni Wilen]

Originally Posted by TuKo

I get a guru with experimental version of pfsdoctor on large partition (>26GB) with lot of files with test #7. Works ok with original pfsdoctor.

Did you check if it runs out of memory? Which guru? (first number)

Fortunately this is non-issue because "old" pfsdoctor is still fully compatible as long as partition is not larger than old max size (104G).

[TuKo]

Monitored RAM during process, it never runs out.

[Toni Wilen]

Originally Posted by TuKo

Monitored RAM during process, it never runs out.

Ok, that guru usually means execution jumped to somewhere where it shouldn't.. Did you try larger stack? (original pfsdoctor may use larger stack by default)

[TuKo]

Indeed, it worked with a stack of 8192 ! I did not thought about it when I saw it working with my first small partitions.

[Toni Wilen]

I plan to finally release official pfs3aio v3 tomorrow. Now that I said it, something is guaranteed to happen in next 20 hours or so

Originally Posted by TuKo

Indeed, it worked with a stack of 8192 ! I did not thought about it when I saw it working with my first small partitions.

4096 default stack is uselessly small.. I'll increase stack if current stack is too small in next update.

[kolla]

Oo! I haven't manage to play around with test7 much (the flue got me, meh), but I have it installed on the CD32/SX32Pro, and there was something new - sometimes on boot-up, the boot device itself, DH0: gurus 8000 0003 or 8000 0004. I know the SX32Pro is an oddball, but since this seems to have started with test7, I should mention it.

[Toni Wilen]

Originally Posted by kolla

Oo! I haven't manage to play around with test7 much (the flue got me, meh), but I have it installed on the CD32/SX32Pro, and there was something new - sometimes on boot-up, the boot device itself, DH0: gurus 8000 0003 or 8000 0004. I know the SX32Pro is an oddball, but since this seems to have started with test7, I should mention it.

None of test #7 changes can cause this, random problem usually points somewhere else. You need to retest with older version #7.