20 August 2020, 14:46 | #1 |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
I managed to upset PFS AGAIN! PFS bug?
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. |
20 August 2020, 20:01 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
The most important question: can you duplicate it reliably?
|
20 August 2020, 23:21 | #3 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,404
|
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. |
21 August 2020, 00:39 | #4 |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
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.
|
21 August 2020, 01:24 | #5 |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
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... |
21 August 2020, 10:38 | #6 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,404
|
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.
|
21 August 2020, 11:28 | #7 | |
Registered User
Join Date: Aug 2014
Location: Brindisi (Italy)
Age: 70
Posts: 8,267
|
Quote:
The first releases of MUI, inexplicably included unnamed files. Last edited by AMIGASYSTEM; 25 September 2020 at 23:19. |
|
21 August 2020, 11:44 | #8 |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
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. Last edited by paul1981; 21 August 2020 at 13:01. |
21 August 2020, 11:48 | #9 | |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
Quote:
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). Last edited by paul1981; 21 August 2020 at 11:53. |
|
21 August 2020, 12:12 | #10 |
Registered User
Join Date: Aug 2014
Location: Brindisi (Italy)
Age: 70
Posts: 8,267
|
Yes I know in my Screenshot what you see are not Images but all icons, with Amiga anything is possible
|
21 August 2020, 12:20 | #11 |
Registered User
Join Date: Oct 2013
Location: England
Posts: 425
|
|
21 August 2020, 12:44 | #12 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,404
|
Files with a filename consisting of spaces are not unnamed files.
|
21 August 2020, 13:05 | #13 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,315
|
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.
|
21 August 2020, 13:27 | #14 |
Registered User
Join Date: Aug 2014
Location: Brindisi (Italy)
Age: 70
Posts: 8,267
|
|
07 October 2020, 06:53 | #15 |
Registered User
Join Date: Sep 2020
Location: San Bernardino, CA, USA
Posts: 4
|
Ah...isn't '.info' a (possibly the only) reserved file ame?
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
PFS 5.3 or PFS 5.1 CD with valid Key ?? | ruliovega | request.Apps | 1 | 30 December 2005 23:54 |
HELP - PFS gone!!! | alewis | support.Hardware | 8 | 26 February 2005 15:10 |
Pfs 2 | manicx | support.Apps | 2 | 25 August 2003 08:57 |
pfs or sfs | oldpx | support.Apps | 14 | 07 March 2003 23:33 |
Pfs | oldpx | support.Apps | 7 | 24 February 2003 09:27 |
|
|