Unable to snapshot in 3.1.4

[rjd324]

Let's say I have just booted up the machine. When I have no backdrop (there is a "workbench window") then I am able to snapshot icons where I want to. But, like a lot of people, I tick that box because I do not want a window.


Now, I am unable to get these icons to snapshot how I want them. The way I do it is that I move the icons where I want them, window>snapshot>all. I have tried all other permutations including selecting them all to see if - somehow - that would make a difference. But, every time I restart they are put back into a malevolent layout.


I heard that someone thought that there had to be plenty of space between the icons. Well, I tried that also, but the same issue occurs.


My icons are: RAM, workbench, programs, other (the latter two being partitions on the same drive as workbench). And, I have an AUX CF named storage. And, I have tried the above with both large icon border and no border.


Can someone help me figure out how to get these icons to stay in benevolent layout?


BTW, I am able to snapshot>all icons that are in windows, just not the "main" screen when there is no "workbench window".

[Daedalus]

Does snapsotting work when you don't use the Backdrop option? There's also the option to snapshot selected icons in the Icons menu, but both work in the same way so it's not likely to make a difference.

Icon positions for volumes are stored in the disk.info file in the root of the volume. Check that this file exists, and that the permissions allow it to be written to.

[rjd324]

I guess creating a video will be easier. Sorry about the unsynchronised frame rate and you'll have to run it in the best resolution to see things better!

Video link: [ Show youtube player ]

Here is Hyperion's definition for Snapshot: https://wiki.amigaos.net/wiki/AmigaO...Using#Snapshot.

There is also Icons>Snapshot further down below. From what I read, I can only see "Window" being mentioned; I think if you display Workbench as a backdrop then it is not a considered a Window. Does this mean undefined behaviour, then? That would explain what I am seeing. But, I do not think this happens on 3.9/3.1.

Anyway, let me know if I am doing something terribly stupid! I really must be, because I cannot find anyone else with this issue.

In the meantime, I might try directly writing to the ICON file using the actual icon library's PutDiskObject() API in a small program at the beginning(-ish) of startup-sequence to see if that makes a difference. All I know is that when I pull the INFO structure using GetDiskObject() the x and y values change again on reboot so - surely - something is writing to them?

[dschallock]

I have had this same issue. Looking forward to seeing the resolution. Thanks for bringing this up.
Good video too!

[rjd324]

Thanks for the reply. I am surrounded in Amigas but too lazy to test this exact same thing out on 3.9 or 3.1. If someone can and confirm that it works in those versions then in my opinion this is a bad thing, although, looking at Hyperion's definition of snapshot you cannot argue that they are not fore-filling what they state, since Snapshot only talks about Windows.

[Daedalus]

Originally Posted by rjd324

I guess creating a video will be easier. Sorry about the unsynchronised frame rate and you'll have to run it in the best resolution to see things better!

That seems very odd indeed...

There is also Icons>Snapshot further down below. From what I read, I can only see "Window" being mentioned; I think if you display Workbench as a backdrop then it is not a considered a Window. Does this mean undefined behaviour, then? That would explain what I am seeing. But, I do not think this happens on 3.9/3.1.

No, a backdrop window is still a window, and snapshotting like that should still work fine, and has always done for me in 3.1.4, 3.9 and 3.1. The snapshotting process iterates through each of the icons in turn, but I think it stops when it encounters an issue so if one of the .info files can't be written, any later on in the queue don't get written either.

Anyway, let me know if I am doing something terribly stupid! I really must be, because I cannot find anyone else with this issue.

I can't see anything obvious that could be causing it, so I don't think it's anything terribly stupid at all

In the meantime, I might try directly writing to the ICON file using the actual icon library's PutDiskObject() API in a small program at the beginning(-ish) of startup-sequence to see if that makes a difference. All I know is that when I pull the INFO structure using GetDiskObject() the x and y values change again on reboot so - surely - something is writing to them?

Indeed, if the actual values in the file are getting rewritten, something else is going on there. Are the changes not getting saved to disk, but to a cache or something? That still doesn't explain why it only happens when in backdrop mode...

Originally Posted by rjd324

Thanks for the reply. I am surrounded in Amigas but too lazy to test this exact same thing out on 3.9 or 3.1. If someone can and confirm that it works in those versions then in my opinion this is a bad thing, although, looking at Hyperion's definition of snapshot you cannot argue that they are not fore-filling what they state, since Snapshot only talks about Windows.

As I said above, it works as you expect it to in all versions from 3.0 on at least, possibly even 2.x too. A backdrop window is still considered a window, and all the relevant window-specific functions still work on it.

[Hedeon]

Are those real icons and not some default icons (like for floppy or CD taken from ENVARC:sys)?

On some systems the disk.info for RAM: is copied every time to RAM: so you need to copy the snapshotted disk.info from RAM: back to where it is copied from.

How about if you draw a rectangle to select them all and do icons->snapshot?

[rjd324]

Yeah, I have tried all of those things. I will upload another video showing me trying the whole deal of selecting multiple icons and then clicking icons->snapshot.

It looks like I am not the only one who has seen this. I have just finished testing a program that FORCEFULLY sets the values to what I want after Workbench pops up. I just put this program in the WBStartup folder and then all my Icons - after a very short delay - just pop back into their proper positions.

I can upload this program a little later. For now, that is the only workaround I have: to forcefully re-trample over the DiskObject structure's X/Y values with the values that I want, and not those that are being - somehow - molested.

[AMIGASYSTEM]

Checked if the hardisk is invalidated ?

[PeterK]

First I've to mention that I didn't read this thread completely.

In a window the workbench can display any desired number of icons at a given position. It can happen that several icons appear at the same position piled up, hiding or overlapping each other.

This is not allowed if the workbench screen is in backdrop mode. Every icon has either a "no position" entry (after un-snapshot) or some x,y coordinates saved in the "#?.info" file. In backdrop mode the WB tries to avoid any overlapping of icons or icon stacks and also reserves some free space around them.

It depends on in which order the icons are loaded by the WB whether an icon can get its given position or not. At the desired position must be enough free space, more than just the icon size. In case that there was already another icon placed into that position or the invisible reserved space around it would overlap with the desired position and the required space for the new icon, then it gets the next free position instead.

I prefer to remove all positions (by un-snapshot) from my disk icons and then the WB always just moves them to the next free position depending on the order of loading after a reboot. Usually, the Ram Disk appears first, followed by DH0, DH1 etc.

But maybe, if you are trying to put your DH0 icon into the first position or something else, followed by other disk icons, then everything may go wrong. The WB puts the first icon without a position, which is the case for all deficons (disks without disk.info) into the next available free position, and that may block one of your other icons with a given position and a chain reaction starts. Left out icons can also cause these position and reserved space conflicts and may be moved to the next free spot by WB.

[rjd324]

PeterK,

thank you for that information. Still, in my demonstration, I create lots of space around the icons and I snapshot them all.

For the time being, I have just created a hack: http://aminet.net/package/util/wb/fim, which I start at WBStartup which solves my problem. But this is not clean and I will continue to investigate.

Will also see if the hardisk in invalidated. By AUX CF card is a just a big FFS partition. My main CF card is a PFS3 split into 3 partitions: how should I check if it is "invalidated"?

EDIT: PeterK, your icon library is excellent with considerable speed increases when loading up windows with many, many entries. Thanks for your work!

[daxb]

PFS is or should never be invalidate. For FFS you can type the command "Info" in CLI to see partition state.

[PeterK]

As I already said, I've removed the positions from all my disk icons with un-snapshot and that avoids any problems with the disks.

But I know these issues very well, because I have many left out tool icons arranged and fixed at the bottom of my Workbench screen where other people like to have a toolbar instead. I prefer to place the tools directly on the WB screen and snapshot them there. That's the point where I often had the same problems as you: after a reboot sometimes some icons where moved by WB to the next free spot below the disks, although the correct x,y position was stored in these icons. But increasing the space between my tool icons could fix this issue. I'm not sure if the space calculation that Workbench does could be buggy in some cases.

I just mentioned these left out icons because the WB saves them in the ".backdrop" files in the root directory of disks. Maybe it can also cause problems if there are "dead entries" of former left out icons in these ".backdrop" text files, although the icons or programs were already deleted from the source drawer, but without using "Put Away" before in the WB menu. Every disk can have a ".backdrop" file, so you may have to check them for garbage.

[rjd324]

PFS is or should never be invalidate. For FFS you can type the command "Info" in CLI to see partition state.

Thanks. Well, INFO shows no issues.

As I already said, I've removed the positions from all my disk icons with un-snapshot and that avoids any problems with the disks.

But I know these issues very well, because I have many left out tool icons arranged and fixed at the bottom of my Workbench screen where other people like to have a toolbar instead. I prefer to place the tools directly on the WB screen and snapshot them there. That's the point where I often had the same problems as you: after a reboot sometimes some icons where moved by WB to the next free spot below the disks, although the correct x,y position was stored in these icons. But increasing the space between my tool icons could fix this issue. I'm not sure if the space calculation that Workbench does could be buggy in some cases.

I just mentioned these left out icons because the WB saves them in the ".backdrop" files in the root directory of disks. Maybe it can also cause problems if there are "dead entries" of former left out icons in these ".backdrop" text files, although the icons or programs were already deleted from the source drawer, but without using "Put Away" before in the WB menu. Every disk can have a ".backdrop" file, so you may have to check them for garbage.

Okay, I have verified that I have no .backdrop files in any partition. I have unsnapped all volumes and ensured that their X,Y locations are essentially "-1".


On reboot:

{Ram Disk} {Workbench}
{Storage}
{Other}
{Programs}

(Btw, I have seen this sort layout above in a few YouTube videos.)

Then, I move icons into the following configuration (there is plenty of space between each icon):

{Ram Disk}

              {Storage}

                                   {Other}


                                                    {Programs}


                                                                       {Workbench}

Select all icons (not Ram Disk), Icons>Snapshot.
Reboot:

{Ram Disk}

                      {Storage}   {Other}  {Programs}        {Workbench}

Then, I move only Storage so it looks like this:

{Ram Disk}

                                 {Other}  {Programs}        {Workbench}

                     {Storage}

Select only storage. Icons>Snapshot.
Reboot:

{Ram Disk}

                      {Storage}   {Other}  {Programs}        {Workbench}

Seems like the X locations are being preserved. But the Y is not.

I do not think it is relevant at all but I am using a GBAPII++ RTG / PiccoloSD64 / Picasso96 and a 1024,768 16 bit resolution.

I still need to check if this actually happens on other OS versions.

For the time being, I still need to apply my FIM program at WBStartup; at the very least, I have a workaround.

[PeterK]

I have unsnapped all volumes and ensured that their X,Y locations are essentially "-1".

No, after a normal un-snapshot the icons should have "No Position" = 0x80000000 stored for x and y, and that is not -1, it is -2147483648. A -1,-1 would be a real position outside of the screen!

ProcessIcon can show you the actual x,y coordinates of an icon, or every hex editor at offset 58 = $3A and 62 = $3E.

But your experiments with setting new positions have indeed very strange results. I will try to reproduce that later.

Update: Couldn't reproduce your position issues on my WB 3.9/3.1.4 system. The diagonal order of the disk icons survives a reboot.

You could also rename or delete ENVARC:Sys/Workbench.prefs. Maybe that causes these strange issues, because it contains a list of hidden volumes, which could be corrupted.

Please upload a few of your disk icons, maybe they have some unusual structure data for size, left edge, top edge ... ??

[rjd324]

No, after a normal un-snapshot the icons should have "No Position" = 0x80000000 stored for x and y, and that is not -1, it is -2147483648.

I forgot to update '-1' which I used as a place holder whilst typing out the post. Indeed, the value is '-2147483648'. I verified this using 'struct DiskObject' for each of the volumes. I did not know about 'processIcon'. Will have a look at that.

I will

• attemp the ENVARC suggestion

• disable my AUX flash card (Storage: volume) using ACA 500+ to see if that makes any different at all

• upload my icon files later

Regards.

[AMIGASYSTEM]

Originally Posted by daxb

PFS is or should never be invalidate. For FFS you can type the command "Info" in CLI to see partition state.

PFS invalidates these files sytem has a tool called "Diskvalid" for automatic correction.


@rjd324
Try running Diskvalid.

Also with PFS it is important to wait a few seconds after saving or copying files, on Amiga not very fast, a sudden restart produces incomplete and corrupted files!

[daxb]

Originally Posted by AMIGASYSTEM

PFS invalidates these files sytem has a tool called "Diskvalid" for automatic correction.

Diskvalid is to check PFS partitions. The invalid state of FFS or its validation process is something different.

[AMIGASYSTEM]

I've been using SFS2/SFS3 on my 4000 for many years and if I didn't have Diskvalid in the startup-sequence to fix the invalidations the partitions would invalidate, this happened rarely without creating problems, now with the new versions I don't know what has changed !
invalidation is different than FFS but can cause the problem to rjd324