problems with new AmiUpdate

I think I manually ignored it in the end using the menus. Its available on os4depot anyway if you should need it.

There seems to be something strange going on with ftp.plignet. AmiUpdate connects OK, but for some reason the server doesn't start the transfer. I've changed the URL of that update and it now works as expected.

Thank for the report.

Simon

Great, works like a charm now :)

I've have the same problem with CopyStore as already described. I've used AmiUpdate to download the archive to RAM: and than tried to install it manually but I sitll get the same error during write operation despite the fact that AmiUpdate is not running. Any tips how to solve this issue or should I wait for next AmiUpdate release?

I'm running AmigaOS 4.1 U2 on SAM440ep.

Copy the Copystore.lha to hard disc.
Reset the Sam and then install copystore.

You have to reset the Amiga because copystore and other prog from Amiupdate are still en the memory.

I have the same problem and after reset, Copystore installs without problems.

Well, this is exactly what I did (clean hardware power on)and it still says that CopyStore is in use (failed to open for writing). It seems that using AutoInstall script always fails while manual copying with WorkBench did the job just right

i have a problem with amiupdate.
first of all i have not used my amiga for 14 days and when i booted it up it complaind about my 30 days tiral for warppng.database or something. then i could not use the left mouse bottum. i rebooted it and delete from a shell wiuth no startup sequence.

then i tyet ami update but it says,cant create the gui have you installed the images ????

whats whong and how to fix it

@retro

Its just you install warpdt datatypes , which are not for free, and which works 30 days and then stop working. PNG images uses everythere (as well as in AmiUpdate i think), and because your datatype not works anymore , you can't use amiupdate.

Solution: remove warpdt and install those ones which come with os4.1 (which not have time limit).

kas1e
so just warpdt has to goo. i cant remember were its located and with one to install after

a little 1,2,3 guide vould be nice

@retro
All right, here we go, 1, 2, 3:

1. All datatypes are stored in the SYS:Classes/DataTypes/ directory.
2. You have to delete png.datatype in this directory.
3. You have to copy png.datatype over from the OS4.1 installation CD.

@trixie

Step 2 is wrong, all WarpDT are named Warp#?.datatype (where #? stands for the datatype in question eg. PNG).
And you forgot the datatype-descriptor.

@retro

You could copy the following source into a file and execute it (to delete the WarptDTs):


After that you have to copy the original datatypes and the descriptors from your CD.

i run the scripts but it was locking for sys: and stuff but i fix it manuely.
and it works now

thanks pepole

Just to let you know, we have released CopyStore 2.6, which should fix the "Object in use" error.

Thanks to Michael Merkel for pointing out the obvious, and for his research into the problem.

Unfortunately, because of the previous bug, it cannot be automatically installed, like any other update. So once downloaded, it must be installed by hand. Please make sure to do this before applying any further updates, as this will enable the automatic installations again.

Apologies for the inconvenience.

Simon

Hi I am having problems solving "copystore failed returncode 20" object not found.

I have copied the copystore file to c:

I have copied it to the amiupdate directory and the modules directory in amiupdate directory, I still have know joy in solving my problem. The installation directions are vague at best, it just says copy copystore manualy thats fine but to where?

please help me.

Quote:
To the main AmiUpdate directory, i.e. the same place where the AmiUpdate program is.

Best regards,

Niels

Quote:

Thanks for your reply, I have copied it to the Amiupdate directory in both it's own folder or by it's self and I still get the same error. I fail to see where I am going wrong the author really needs to find a better installer solution.

@Fairdinkem

Is the executable bit set?

Quote:
Like broadblues suggests, check if the E flag is set.

Quote:
I believe there were some special problems with a recent update, where some of the programs in the package were updated simultaneously and "got in the way" of each other or something. Normally updates of the AmiUpdate modules does happen smoothly and automatically.

Edit: P.S. BTW, maybe we are misunderstanding the error condition. Maybe CopyStore itself is found all right, but the object not found is the one it tries to copy? What are the exact steps you are doing when the error appears?


Best regards,

Niels

Perhaps enabling the "debug install scripts" option might give more information about why its failing.

Simon

Or use Snoopy...