TinyLauncher working on FFS formatted .hdfs, but not on PFS .hdfs

[bladecgn]

First off, as it's my first post in this forum (have been reading it for ages though) thank you so much Toni for this great emulator !

Now then, I've got a little problem: recently I transferred my OS 3.9 and 3.1 .hdfs (formatted with FFS) to PFS3 (using Toni's PFS AIO solution).

Everything is working great and it's a whole lot faster. But TinyLauncher does not work anymore, saying "I/O Error" on startup. It is still working with the FFS formatted .hdf

So it could have sth. to do either with WinUAE itself or the PFS AIO Implementation.

[Toni Wilen]

I'd first check if drive contents are really identical, including possible device names in config files.

There was similar problem with some launcher (not sure which one it was) and difference was single tiny config file in S: directory.

[bladecgn]

Originally Posted by Toni Wilen

I'd first check if drive contents are really identical, including possible device names in config files.

I copied the entire drive content (where tinylauncher is working) from the FFS formatted hdf with "copy dh0:#? all clone xh0:" to the PFS hardfile which went without error.

xh0: was the freshly formatted PFS hardfile (pfsformat drive xh0: name Test noicons quick). Even changed the Name afterwards from Empty to "WB_3.1" and from xh0: to dh0:.

Result: TinyLauncher not working.

Now I formatted the FFS hardfile again with FFS and copied the content of the PFS hardfile to it. Result: TinyLauncher working again(!)

So... it must have sth. to do with PFS I think...

[Toni Wilen]

Does original PFS3 have same problem (available also from Aminet)? I'd say it has to be bug in application, filesystems can have small differences that are not considered bugs. It could even be bug in FFS that was kept for compatibility purposes

Can you create minimal HDF that can be used to trigger the error? (no WB files, does not need to be bootable)

[bladecgn]

Originally Posted by Toni Wilen

Does original PFS3 have same problem (available also from Aminet)? I'd say it has to be bug in application, filesystems can have small differences that are not considered bugs. It could even be bug in FFS that was kept for compatibility purposes

Can you create minimal HDF that can be used to trigger the error? (no WB files, does not need to be bootable)

Original PFS from Aminet works!! I used "PFS3" as FileSys instead of pfs3_aio-handler.

I could create such an image but it might be easier if you happen to have a PFS .hdf with OS 3.1 or 3.9 to boot the OS. Then just extract TinyLauncher to RAM: and execute it. http://aminet.net/package/util/misc/TinyLauncher

The SYS: partition needs to be a PFS .hdf.

So this is not a WinUAE but a pfs3_aio-handler problem. Now all we have to do is to trackdown the guy who programmed it. Who might that one be? ;o)

[Toni Wilen]

Originally Posted by bladecgn

Original PFS from Aminet works!! I used "PFS3" as FileSys instead of pfs3_aio-handler.

I could create such an image but it might be easier if you happen to have a PFS .hdf with OS 3.1 or 3.9 to boot the OS. Then just extract TinyLauncher to RAM: and execute it. http://aminet.net/package/util/misc/TinyLauncher

The SYS: partition needs to be a PFS .hdf.

So this is not a WinUAE but a pfs3_aio-handler problem. Now all we have to do is to trackdown the guy who programmed it. Who might that one be? ;o)

Actually PFS3 AIO is based on PFS3 SVN version which has lots of fixes and updates by other developers. I only added NSD/autodetect and KS 1.x support, I didn't touch anything in filesystem logic itself.

I'll try to test TinyLauncher..

[Toni Wilen]

Not tested yet but it seems to be caused by this change:

Revision: 9
Author: michielp
Date: 15. April 2011 12:05:03
Message:
Issue 3286818: shared lock for ACTION_FINDOUTPUT.

----
Modified : /PFS/trunk/dd_funcs.c

Guru Book says ACTION_FINDOUTPUT should use EXCLUSIVE LOCK but this patch changes it to use SHARED_LOCK.

Unfortunately I have no idea what "Issue 3286818" means.

Tinylauncher expects Lock("s:tinylauncher/tinysys.cfg",SHARED_LOCK) to fail if config file was already opened in ACTION_FINDOUTPUT mode.

EDIT: Issue is this:

ACTION_FINDOUTPUT should have a fully shared lock. Currently it is single writer, mulitple reader. This could be as simple as changing line 696 of dd_funcs.c which currently states
type.flags.access = ET_EXCLWRITE;
to
type.flags.access = ET_SHAREDWRITE;

But this can't be correct, Amiga filesystems do not work this way.

[Retrofan]

I don't have an idea about what the problem is with PFS3, but it also fails with SkinnableClock. In this case it doesn't let you save the changes you make after a reboot, and that's only when using PFS3/AIO.

Originally Posted by James

Are you using PFS? I have encountered this problem with a new system install on WinUAE (installed ArtEffect4, ran it for half an hour but after a reboot it was gone). I think SkinnableClock might interfere with the Atomic Commit feature of PFS under certain conditions. But if you are not using PFS then that theory is totally wrong.

[Toni Wilen]

I'll attach test version later with above "fix" reverted. (After build works again, something has changed in aros m68k build system)

[Toni Wilen]

Test version attached. Not for production use, you are on your own!

Tinylauncher confirmed working now (Note that you must delete invalid zero size config file in s:tinylauncher first)

[bladecgn]

I can confirm TinyLauncher working now... thanks a lot!