I managed to upset PFS AGAIN! PFS bug?

[paul1981]

OS3.0, no patches.

I created a tool icon on its own with the same name as a command in my path (with .info extension of course) so that it loads the command when double clicked. All is well, then I thought why not rename it to nothing so that I can just see the icon and no text. I did and was greeted with the following error requester:

----------------------------------------
PFS-III Error Requester
Device DH0:
ALERT:
Wrong dirblock id 0000e310 block 4103371
----------------------------------------

I pressed the Ok button and was then greeted with:

--------------------------------
Software Failure
DH0
Program failed (error #80000027).
Wait for disk activity to finish.
--------------------------------

I pressed Suspend but DH0 task had failed so Workbench was not responding anyway. I quit WinUAE and backed up the image.

After the backup, I loaded WinUAE again and went into Workbench and ran the pfsdoctor tool and everything seemed to be okay, as per when I had my last trouble https://eab.abime.net/showthread.php?t=101920
(If you are reading this Toni I have a question in that thread at the end)

I checked in the drawer for the icon I created and it was still there, but obviously it was called ".info" and so Workbench hides it as it has no file to bind it to. This is correct behaviour for Workbench 3.0 and 3.1 (and probably earlier releases too), but what isn't correct is the PFS Error (I get no such error on my 3.1 setup with standard FFS). OS 3.1.4 doesn't let you do this, it requires a single character and so this error would never show up. 3.1.4 is a bit weird actually as if you try and rename something to nothing it doesn't do anything (doesn't even tell you why it didn't do anything).

I didn't expect it to let me rename it to nothing to be honest, I expected I'd have to put a space in, much in the same way as it complains if you try and rename a drawer to nothing - you can't do it of course, but because this is actually a .info it is perfectly happy to chop off the xxx from xxx.info and leave you with nothing (well, the icon disappears from view). OS3.1.4 fixes this in Workbench luckily, as I believe it was a bit of an oversight by Commodore.

I've found 15-20 bugs in Os3.0 as of yet. Not sure how many of those exact ones still exist in 3.1.4.1, but that'll be fun for another time.

[Toni Wilen]

The most important question: can you duplicate it reliably?

[Daedalus]

Hmmm, I do wonder at the wisdom of having a file with effectively no name. I appreciate you shouldn't be able to do anything that breaks something, but it's a very strange way to achieve what you want to do. I guess you were renaming it with Workbench? Maybe renaming it as a single space would be a better approach (so your icon would have a space before the .info), as Workbench is known at least to deal with that fine.

My guess is that Workbench looks for a file with a null string for a name (your icon without the .info extension), since that is part of the renaming process for Workbench, and the filesystem perhaps quite reasonably doesn't expect a filename of "", which instead refers to the current directory in AmigaDOS terms. Renaming the icon in AmigaDOS won't look for the "" file to also rename, so that should work fine.

[paul1981]

Originally Posted by Daedalus

Hmmm, I do wonder at the wisdom of having a file with effectively no name. I appreciate you shouldn't be able to do anything that breaks something, but it's a very strange way to achieve what you want to do.

No, it had a .info extension, so I was renaming the icon via Workbench GUI. Workbench surprisingly let me rename it to "" as you mentioned, and hence it disappeared from view because it was just ".info" now.

[paul1981]

Originally Posted by Toni Wilen

The most important question: can you duplicate it reliably?

Right, I've been working on a backup so got to play around a bit. I wreckon I got a detail wrong in my original description of what leads to the error, so here it is:

Rename the visible icon (let's say a tool icon called "More" for example)...rename it to nothing. Then, rename it again to anything, such as "foo" and this is where I get the exact same PFS-III Error Requester with the exact same details on, so repeatable yes.

I next tried doing the same thing in the root directory. From here, I could not replicate the fault at all, it behaved itself.

Then, I tried it inside the System drawer on the root and I didn't get a PFS-III Error Requester, but I did get a Software Failure as the first post:

--------------------------------
Software Failure
DH0
Program failed (error #80000027).
Wait for disk activity to finish.
--------------------------------

I rebooted, and I noticed my System drawer had disappeared (System.info still there, but no System drawer). I ran pfsdoctor dh0 check, I'll post the interesting bits:

-----------------------------------------------
Monitors 0...
Keymaps 0...
DataTypes 0...
Rexxc 0...
0...
DIR /Rexxc/
ERROR:Corrupt directory block
DIR /Rexxc
ERROR:Corrupt directory entry
L 0...
FileSystem_Trans 0...
S 0...

...

Validating reserved 16...
ERROR:1 reserved blocks not used but allocated
ERROR:Wrong number of reserved blocks free
Validating main 2039...
ERROR:202 data blocks not used but allocated
Validating anodes 10625...
ERROR:15 anodes not used but allocated
finishing up 2...
-----------------------------------------------

I had a look inside the Rexxc drawer and it appears that my System drawer is now in there, but it's not called System anymore, it is now just 4 spaces. I go in there and everything is there, including the blasted ".info" file.

Now, if I click on any of the programs with an icon in there such as NoFastMem or Format for example, I get a invalidation requester from Workbench presumably, see below pic, and if I cancel it it loads fine. If I load those same programs via the Shell, I get no invalidation requester at all and they load fine. I daren't try this on my OS3.1 FFS now incase it cocks it up. I'll certainly make a backup first if I do...

[Daedalus]

Originally Posted by paul1981

No, it had a .info extension, so I was renaming the icon via Workbench GUI. Workbench surprisingly let me rename it to "" as you mentioned, and hence it disappeared from view because it was just ".info" now.

Yeah, I understand that, but from Workbench's perspective, it's renaming a file to "", and also renaming the file's icon to ".info", and it's the attempt to do the first part (even though it doesn't exist) that I suspect is causing the trouble, perhaps because "" refers to the current directory, and attempting a lock on it will likely be successful, even though the file doesn't exist. It shouldn't really let you do that IMHO, but then again there are plenty of things you just shouldn't do on the Amiga that aren't enforced.

[AMIGASYSTEM]

Originally Posted by Daedalus

Hmmm, I do wonder at the wisdom of having a file with effectively no name.

I also use to delete the name from the icons, this can be used to show the icons without the text, of course you have to be careful otherwise you overwrite the one with the same name (i use SFS).

The first releases of MUI, inexplicably included unnamed files.

[paul1981]

I have just tested this with a backup of my 3.1 installation. This has no patches, standard FFS (40.1 iirc) and I cannot repeat the error. Workbench allows the icon to be renamed to nothing and then renamed again to something (don't select Update after the first rename or the icon will become hidden). I tried this in a subdir and in the root, no issues at all.

I then tried it with Kickstart 3.0 and rebooted (the same 3.1 FFS installation) and again, no issues at all.

Apologies, before when I said there were no patches in my 3.0 system. that's not quite true as I am using the PeterK icon.library and PatchOpenWB from the NewIconspackage, and other little bits I had forgot about, but I have just now tested the issue again with extra stuff/patches removed and I still get the same trouble, so it's nothing to do with the few extras I am running.

Also, just now tested my 3.0 installation with a FFS floppy disk (don't know why I didn't think of that earlier), and like my 3.1 installation there are no issues whatsoever, tried root and subdirs...it behaves itself correctly.

[paul1981]

Originally Posted by AMIGASYSTEM

I also use to delete the name from the icons, this can be used to show the icons without the text, of course you have to be careful otherwise you overwrite the one with the same name (i use SFS).

The first releases of MUI, inexplicably included unnamed files.

You can't have unnamed files, there's always something, usually a space but yes, I have used these so called 'blank icons' from time to time as they do come in handy. I like to test things to destruction too.

I'll tell you what also comes in handy - space(s) before and after filenames so that you can have files with seemingly the same name (keeps text in the center).

[AMIGASYSTEM]

Yes I know in my Screenshot what you see are not Images but all icons, with Amiga anything is possible

[paul1981]

Originally Posted by AMIGASYSTEM

...with Amiga anything is possible

Yeah, that's half the problem sometimes.

[Daedalus]

Originally Posted by AMIGASYSTEM

I also use to delete the name from the icons, this can be used to show the icons without the text, of course you have to be careful otherwise you overwrite the one with the same name (i use SFS).

The first releases of MUI, inexplicably included unnamed files.

Files with a filename consisting of spaces are not unnamed files.

[daxb]

DOpus5 has an option in "icon information" to disable icon text. You may ask the OS 3.1.4 developer if they willing to add such a feature. At least it would be the better way instead of renaming.

[AMIGASYSTEM]

Originally Posted by Daedalus

Files with a filename consisting of spaces are not unnamed files.

Yes shown in my screenshot

[pgf_666]

Ah...isn't '.info' a (possibly the only) reserved file ame?