icon.library 46.4 test versions

[hexaae]

Now if you

copy 239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234567899123456789112.jpg ram:239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover7898123456789912345678911234567.jpg

nothing will happen (with V45 the file gets copied, using all 107 chars). WBCtrl MNL 102.
Mmmh shouldn't it prevent only exceeding .info files from WB in case the file has one and fail the copy process? But if the file has no info should let you create one with 107 chars... Maybe I'm wrong, or maybe v45 was too permissive? Actually v45 could lead you to a case where file gets copied but icon not created from WB (RAMIGA+C)… With your v46 now the safety check is done before the copy actually limiting you to 102 chars files, even if limit is 107… mmh
But from shell the OS should let you create 107 max char limit files (without icons). Still not sure though… (a bit tired)

P.S:
If you press RAMIGA+R to rename the file from WB you can still enter up to 107 chars, and at this point if you press Enter to confirm, the file will simply disappear without any warning (odd!??)
P.P.S:
another strange thing is that now WB screen appears early in the Startup-Sequence (icon.library in search of WB screen that as a side effect of a lock pops-up too early before LoadWB?)

[kolla]

I feel too dumb to follow this now... what does C:Copy have to do with icon.library and .info files? AFAIK, only Workbench (and its "clones") care about .info files, and copying jpeg files from shell doesn't do anything with .info files. What am I missing?

[PeterK]

Copying 102 chars to 107 works here. Not creating an icon is correct.
Renaming 102 chars to 107 with a disappearing icon is correct. The user must know what he does.

What do you mean with "icon.library in search of WB screen"? What kind of lock pops up?

@kolla
I would think just the same about the copy instruction.

[hexaae]

Originally Posted by PeterK

Copying 102 chars to 107 works here.

WBCtrl MNL 102, following command will result in no file in ram (does work with v45 instead):

copy 239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234567899123456789112.jpg ram:239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover789812345678991234567891123.jpg
(102 from HD location) to (103 in RAM)

Renaming 102 chars to 107 with a disappearing icon is correct. The user must know what he does.

If you try to rename a 102 chars long file in ram with icon.lib v46 using WB (RAMIGA+R) and giving it 103+ chars the whole file will vanish (opening RAM from WB)! This doesn't happen with V45 again: the renamed file with 107 char is present.
It would be normal failing to rename the icon only (too long with +5 chars) but in this case, from WB (RAMIGA+R), without warning it works like a delete command on any file above 102 chars (EDIT: it's not actually deleted, but WB won't show it in ram!)

Repro steps:
- WBCtrl MNL 102 and then copy a 102 chars file (without icon) in ram:
- open RAM, click on file def_icon and press RAMIGA+R to rename it
- give it a 107 chars long name and press Return
- the file will be vanished!

What do you mean with "icon.library in search of WB screen"? What kind of lock pops up?

When latest icon.lib v46 is loaded (I use LoadModule + SetPatch 44.38) the WB title appears during SSeq instead of keeping the classic black screen 'till LoadWB… Didn't happen with previous icon.lib v46.

[PeterK]

Everything just works correctly here. If you use rename for the icon on WB (RAMIGA+R) and the new name is too long for the deficon but ok for the filename, it's logical that the icon has to disappear, but the file is renamed as it should. Use the list command.

If the icon of the old file was a real icon, it also remains without the old file. You have to update the drawer to see the old icon. That's also logical.

Using LoadModule or LoadResident and SetPatch v44 makes no sense, since SetPatch loads icon.library and workbench.library anyway. But I'm going to check that soon.

Update: Checked that with LoadModule, but there is no early opening of the Workbench. It must be something else in your startup-sequence.

[hexaae]

This is a misunderstanding: I'm working with no icons. Copy bare files without icons and in RAM rename the same file from 102 to 107 chars with RAMIGA+R from WB.
I use Deficons with Newicons but I don't think it can have something to do with this, also because it's not reproducible just switching back to icon.library v45.

About WB title popping up early if I revert to V45 or old v46 the glitch disappears. The only variable changed is icon.lib v46.

P.S.
Of course I use LoadModule to load also other things, that's why I use it.

[PeterK]

Sorry hexaae, it's not a misunderstanding. Of course, I have done all my tests without real icons, just with deficons, and everything works as you can see in my screenshot with the shell window.

Only a final test was done with a real icon to check how that behaves on renaming from 102 to 103+ chars. That's also ok.

I think, you still don't understand that icon.library v45 causes a buffer overflow which may result in memory corruption and even a crash sometimes. I had such memory corruptions when I tried to load the renamed deficon (103+ +.info) into WB Icon Information to save it as a real icon: Bang!

Icon.library is not a task and never opens the WB by itself. So what is in your startup-sequence that calls icon.library and needs access to the WB?

And again, on a system with SetPatch v44 icon.library and workbench.library are loaded from Libs: anyway if SetPatch finds them there, unless you are using the option DISABLEROMMODULES "" which is not the same as SKIPROMMODULES for other libraries, handlers and devices. By default Setpatch removes icon.library and workbench.library from the resident list and thus makes LoadModule and LoadResident pointless. It seems that ThoR has changed LoadModule to work together with SetPatch DISABLEROMMODULES "" now. Some years ago he told me that this SetPatch option is not working correctly, but it works now, so he must have fixed LoadModule. You can check that in Scouts resident list.

[hexaae]

With icon.library 46.4.487 + WBCtrl MNL 102, after a

copy 239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234567899123456789112.jpg ram:239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover789812345678991234567891123.jpg
(102 -> 103 chars in ram)

When you open RAM from WB (don't use C:List from shell… that is correctly displaying the file in ram, no doubt about it) it won't display the file icon of 103 chars (using its def_icon since it has no .info file), that's what I'm saying. If you rename the file under 103 chars it will reappear in WB ram.
workbench.library 45.132 (or 45.138) and no patches/hack installed.
ram-handler from OS3.9 (don't use amber-ram or similar).

About the annoying WB title popping up before LoadWB I'm also sure is present only when I use icon.library 46.4.487
Both issues are not reproducible using v45 or previous v46.4.481 from Aminet.

[PeterK]

How often do I need to repeat myself? A name with 103 chars + .info or more is not a valid name and can not have an icon if you don't want to get a buffer overflow. So, it's correct that there is no (def)icon and v45 - 46.4.486 have an issue when they don't care about invalid names. 487 fixes this long-standing bug.

I just did such a rename (102 -> 103) with RAmiga-R under v45 again and I get Enforcer hits as soon as I try to save the deficon with Icon Information:

You still didn't tell me which program in your startup-sequence, user-startup or WBStartup causes the early opening of the WB screen or title. I'm adding my internal sub-versions now, so that you can check when exactly this issue starts.

[hexaae]

Originally Posted by PeterK

I think, you still don't understand that icon.library v45 causes a buffer overflow which may result in memory corruption and even a crash sometimes. I had such memory corruptions when I tried to load the renamed deficon (103+ +.info) into WB Icon Information to save it as a real icon: Bang!

Assuming you're not using buggy RAWBInfo (it's known to have issues also when you try to drag'n'drop very big Coloricons >94x100 to change icon image) but original workbench.library/WBInfo()...
I have v45.5 (is this one you tested? It's a mess with all official/unofficial versions around...) and your test is impossible to do here: if I try to rename from shell (I'm in RAM directory):

ren 239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234567899123456789112.jpg.info 239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover789812345678991234567891123.jpg.info

will result in ram:239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover789812345678991234567891123.jpg.inf
truncated, still safe within 107 chars…

workbench.library 45.132
icon.library 45.5

[PeterK]

Ok, I've tested with RAWBInfo first and it caused Enforcer hits on saving. With WBInfo 45.1 there was no hit. I will check that later.

[hexaae]

Originally Posted by PeterK

How often do I need to repeat myself? A name with 103 chars + .info or more is not a valid name and can not have an icon if you don't want to get a buffer overflow

Peter, this is obvious and I know it. The point is: how to prevent this? Automatically truncating filenames in all attempts to create such file names (original WB3.9 approach, at least with workbench.library 45.132 and icon.library 45.5 apparently without WinUAEEnforcer hits or memory corruption from my tests), or silently doing nothing and not creating the illegal file name…?

I just did such a rename (102 -> 103) with RAmiga-R under v45 again and I get this error in WinUAElog.txt with Enforcer running as soon as I try to save the deficon with Icon Information:

With 45.5, doing RAMIGA+R, the icon file "23...….103.info" is automatically truncated from 103(+5)->102(+5) "23.... 103.inf" in the attempt…
Can you please list what you did step by step (maybe I misunderstood something…)?
EDIT:
Oh, as I supposed you used buggy RAWBinfo, now I understand when you wrote "..I try to save the deficon with Icon Information", not present in the original WBInfo() window.

You still didn't tell me which program in your startup-sequence, user-startup or WBStartup causes the early opening of the WB screen or title.

I tried also using nothing (renamed WBStartup and disabled MCP from my sseq), my sseq here and here my ustartup. But I still can reproduce it.

I'm adding my internal sub-versions now, so that you can check when exactly this issue starts.

Thank you, that's serious version management
… here is the result:
with version 'b' started the strange "WB title pop-up" before LoadWB
with version 'f' started the issue with file (def_icon, since it has no real icon) not shown in WB ram if >102 chars (but you can still list it from shell…)

[AMIGASYSTEM]

Originally Posted by PeterK

Update to icon.library 46.4.487:

This update has not been tested very much yet.

Ciao Peter, with 487 i found a strange thing with OS 35/3.9, now i do not know if it's my system's fault, files with type name "Nuovo documento di testo.txt" or "Nuovo Documento di Microsoft Word.doc" they are not seen .


Another strangeness it's on your LHA archives, if dragged on the Workbench and they are active both DF0 and DF1, we will find the archive inserted in both floppies (file icon.library.46.4.487_68000 DF0 and file icon.library.46.4.487_68020 DF1), i think it depends on the type of files contained in the archive, i tried to create a file ZIP and the same thing happens

I enclose a video showing the two oddities reported.

[PeterK]

with version 'b' started the strange "WB title pop-up" before LoadWB
with version 'f' started the issue with file def_icon

487b was the fix for the FileX bug. I've removed some code where I could not remember anymore why I once added it. That is your WB issue now! The disabled code checks if WB is already open before it allows to read the palette mapped icon data as used by OS 3.5+. I've also disabled the GetDO_PlanarTags which was probably used by the FileX appicon via GetDiskObjectNew() and GetDO_NoFailTags and has caused the missing icon.

I think the solution should be to enable the code in GetDiskObject() again to fix your WB problem and to remove the tag ICONGETA_GetPaletteMappedICON=0 in GetDO_NoFail_Tags only to fix the FileX problem.

That your other problem with the disappearing deficons started with 487f was clear. I'm going to check that again if it might cause possible issues in other programs like the crash with RAWBInfo before I go back to 487e.


@AMIGASYSTEM
Are you using a tool like ArcHandler or something similar to automatically mount the contents of archive files? Which tool is that?

What is your disk "pippo:" exactly, which filesystem is that?

[kolla]

Originally Posted by PeterK

@AMIGASYSTEM
Are you using a tool like ArcHandler or something similar to automatically mount the contents of archive files? Which tool is that?

I think this is an exotic feature of WinUAE

[PeterK]

Originally Posted by kolla

I think this is an exotic feature of WinUAE

Indeed, you can mount lha files with the WinUAE floppy drives! Hoorray!!

@AMIGASYSTEM
Please eject your floppy disks from DF0: and DF1: and reboot again.

Maybe you have typed some keyboard shortcuts / hotkeys that WinUAE uses to mount the floppy drives? But don't ask me which shortcuts that are. I don't know. Ask Toni. Maybe, it's a feature of uaecontrol, but I don't use that.

[hexaae]

@PeterK
RAWBinfo has always been buggy unfortunately (random memory corruption or partially incompatible with some icons), including latest (un)official versions 1.36+. Another example: if you try to drag'n'drop this big Coloricon (yes, exceeds 94x94) over another project to copy the icon it may crash or open a "Not enough memory available" warning (?).
If you disable RAWBinfo, and you drag'n'drop that icon over another project using original WBInfo() window you'll see no issues…

The best was SwazInfo, but even with latest patches post-OS3.5 it still has problems handling NewIcons + Coloricons… AFAIK David Swasbrook never released source code to let someone continue his great WBInfo() replacement

[AMIGASYSTEM]

Originally Posted by PeterK

@AMIGASYSTEM
Are you using a tool like ArcHandler or something similar to automatically mount the contents of archive files? Which tool is that?

No, WinUAE automatically decompresses all the most common compression formats like LHA, LZX, ZIP, RAR, without the need for external programs showing the contents in a folder (only RAR archives require PlugIn UnRAR.dll).

What is your disk "pippo:" exactly, which filesystem is that?

Pippo was a simple Windows folder, but also the single archive file dragged is handled the same way.


I attach my old video that shows how WinUAE handles many file formats including archives.


[ Show youtube player ]

[AMIGASYSTEM]

Originally Posted by PeterK

Indeed, you can mount lha files with the WinUAE floppy drives! Hoorray!!

Yes if the archives include executables or floppy image files

@AMIGASYSTEM
Please eject your floppy disks from DF0: and DF1: and reboot again.

I think I know this , with OS 3.1, it occurs only if you double-drag the file , at the first drag there is no hijacking in the floppy players, if you drag a file the second time you will find the two executables in floppy playersy .

[kolla]

I suspect you get more "floppies" mounted when the archive doesn't contain a root directory.