Available now: AmigaOS 3.1.4

[keith.f.kelly]

NOTE: There's apparently a BUG in the readme/instructions included with the AmigaOS 3.1.4 release. The instructions for opting into using the new intuition.library say to modify S:Startup-Sequence to use...

C:LoadModule ROMUPDATE

...but that doesn't work, because LoadModule complains with...

filesystem version 46 already resident.
Loading filesystem failed: object already exists

...and aborts without doing anything. To force it to load LIBS:intuition.library, I had to resort to the following instead...

C:LoadModule LIBS:intuition.library

...and then it worked (as confirmed via "LoadModule LIST" after the reboot) and I was finally able to drag windows off the screen edges.

[Olaf Barthel]

Originally Posted by AC/DC HACKER!

Is "FFS" as an argument required??

No, none of the "file system flavour" selection arguments are required. Their purpose is to allow you to override the defaults which Disk Doctor picks from the file system configuration that is currently active. The flavour selection is only needed if the active file system configuration is inadequate.

For example, if you reformatted a volume which previously was in OFS format to use FFS format and then want to recover later what's still left of the OFS data, you would use the "OFS" switch.

You made it, so you've used it. It's finding files and lists stuff very fast, I can tell it's noticing files that are there and has not reported ANY problem, so...I'm confused. I'm betting I'll type, "Duuuhh!" once you inform me. MY thought is that it's going to just copy what it's able to the destination; which is "In Use" but not.

Well, this is a bug in my program which slipped the testing process

When you use the COPY operation Disk Doctor will re-create each directory present on the source volume needed to reconstruct the entire directory tree. To this end Disk Doctor first tries to create the directory in the destination path, checks if it worked, and if not, if the directory creation failed because there was an error which requires that the copy operation be stopped (e.g. the destination may not be mounted, there was a read/write error, etc.).

Directory creation can fail if the directory already exists, which should be harmless. Disk Doctor checks for that condition and moves on. But a directory creation can fail, too, if the directory exists and a program already uses it as its "current directory": this is what tripped up Disk Doctor because some file systems will not report this as an error of the type "the directory already exists" but as an error of the type "somebody is currently using that directory and it cannot be overwritten".

There you have it, the kind of bug which should have been detected earlier but which depended upon the actual file system behaviour which can vary. In this case "diskdoctor copy hard-disk: to ram:dir" will work, but "diskdoctor copy hard-disk: to other-hard-disk:" may not. The automated test rig which fed hundreds of ADF images into Disk Doctor, exercising the COPY operation, always used a directory in RAM: as its destination path. This always worked, which is why the problem went undetected and unreproduced

I just figured out what went wrong, and an update to Disk Doctor will be made available as soon as possible. As you may have expected, the really tricky bugs are discovered only after the software has been released to a greater audience...

[Romanujan]

I have purchased the 3.1.4 (for now two licenses...), and I'm going to integrate these with my current installation. But I've got some questions regarding patches I use - do I still need them, or are some of them already integrated with 3.1.4? For some I have found answers in the FAQ or other threads, for others I have no idea yet:

- IntAckFix - http://aminet.net/package/util/boot/BK_IntAckFix
- RangerMem - http://aminet.net/package/util/boot/bk_rangercheck
- BetterOpenLibs - http://aminet.net/package/util/sys/BetterOpenLibs
- TagLiFE - http://aminet.net/package/util/boot/TagLiFE
- BlazeWCP - http://aminet.net/package/util/boot/Blazewcp
- FBlit - http://aminet.net/package/util/boot/fblit, http://cosmosamiga.free.fr/download/...library.readme, http://cosmosamiga.free.fr/download/fblit_library.lha
- FText - http://aminet.net/package/util/boot/FText
- CpuBlit - http://aminet.net/package/util/boot/CpuBlit
- copymem speedup patches

And - is there any way to get the updated expansion.library for creating my own custom ROM (for emulation / FPGA / maprom usage)?

[DanyPPC]

For may experience it is best to use Blizkick only to map the Kick46143 file, without any module.

I use in order BlazeWCP, FBlit and FText.
I haven't read on F.A.Q. nothing about these patches.

[DanyPPC]

I read about the new OS has function to use Fast ram when available, but when i open various windows chip ram is lowered.
On OS3.9 i use WBCtrl which has no effect on 3.1.4

It's simply a bug or there is an option to activate to exploit Fast Ram on my Blizzard 1230 mkIV ?

Thanks for your attention.

[xterc]

Originally Posted by keith.f.kelly

NOTE: There's apparently a BUG in the readme/instructions included with the AmigaOS 3.1.4 release. The instructions for opting into using the new intuition.library say to modify S:Startup-Sequence to use...

C:LoadModule ROMUPDATE

...but that doesn't work, because LoadModule complains with...

filesystem version 46 already resident.
Loading filesystem failed: object already exists

...and aborts without doing anything. To force it to load LIBS:intuition.library, I had to resort to the following instead...

C:LoadModule LIBS:intuition.library

...and then it worked (as confirmed via "LoadModule LIST" after the reboot) and I was finally able to drag windows off the screen edges.

This happens when you have files left over from a previous installation that have the 'pure' attribute set. LoadModule scans the appropriate directories for files with this attribute set and attempts to load them. Use the protect command with -P switch to remove the attribute.

[AC/DC HACKER!]

Originally Posted by Olaf Barthel

No, none of the "file system flavour" selection arguments are required. Their purpose is to allow you to override the defaults which Disk Doctor picks from the file system configuration that is currently active. The flavour selection is only needed if the active file system configuration is inadequate.

Yuuuuup. Makes logical sense to me.

For example, if you reformatted a volume which previously was in OFS format to use FFS format and then want to recover later what's still left of the OFS data, you would use the "OFS" switch.

Same as what DiskSalv 4 did/does..when it scans if you leave Best-Guess. Or if you pick one, and it checks it anyway and prompts for you to choose.

Well, this is a bug in my program which slipped the testing process

When you use the COPY operation Disk Doctor will re-create each directory present on the source volume needed to reconstruct the entire directory tree. To this end Disk Doctor first tries to create the directory in the destination path, checks if it worked, and if not, if the directory creation failed because there was an error which requires that the copy operation be stopped (e.g. the destination may not be mounted, there was a read/write error, etc.).

Exactly what I was expecting.

Directory creation can fail if the directory already exists, which should be harmless. Disk Doctor checks for that condition and moves on. But a directory creation can fail, too, if the directory exists and a program already uses it as its "current directory": this is what tripped up Disk Doctor because some file systems will not report this as an error of the type "the directory already exists" but as an error of the type "somebody is currently using that directory and it cannot be overwritten".

There you have it, the kind of bug which should have been detected earlier but which depended upon the actual file system behaviour which can vary. In this case "diskdoctor copy hard-disk: to ram:dir" will work, but "diskdoctor copy hard-disk: to other-hard-disk:" may not. The automated test rig which fed hundreds of ADF images into Disk Doctor, exercising the COPY operation, always used a directory in RAM: as its destination path. This always worked, which is why the problem went undetected and unreproduced

In my last tests, I booted my A4000 to Without a Startup-Sequence and then ran DiskDoctor HD-Partition: to HD-Partition AND also attempted HD-Partition: to RAM:. Both ended the same way as I reported. I hadn't considered booting my 3.9 install and running it from there using the same Partitions or RAM:. I might give that a go because I didn't consider a Locked file..as a possibility.

[QOUTE]I just figured out what went wrong, and an update to Disk Doctor will be made available as soon as possible. As you may have expected, the really tricky bugs are discovered only after the software has been released to a greater audience...[/QUOTE]

Oh, for sure! Actual Usage results are very helpful for programming. Much better than a bunch of people sitting in a room using computers that have the exact same install (all the same programs) and attempting to get it all found before release. It's also the reason I prefer to either Bug-Hunt myself or use DuckDuckGo.com to help me find solutions, because calling most businesses now and getting Tech Support that is run from scripts aren't very helpful--where actual experience or documented stuff is.

Excited to check the new update. Also, wondering, is a GUI planned? Appreciate the reply. I'm still insane, but not ThhhhhhAt wa-wa-way. Haha!

[AC/DC HACKER!]

Originally Posted by DanyPPC

I read about the new OS has function to use Fast ram when available, but when i open various windows chip ram is lowered.
On OS3.9 i use WBCtrl which has no effect on 3.1.4

It's simply a bug or there is an option to activate to exploit Fast Ram on my Blizzard 1230 mkIV ?

Thanks for your attention.

I've wondered about that some also, though I use A4000 CyberStormPPC/060, I wondered why the CHIP is still being used. It's not much usage, but.. That's the one thing I like about 3.9, it's very speedy because of not using CHIP, and I have Workbench displaying on Picasso 4 screen which helps.

CyberStormPPC 128MB
BigRamPlus 256MB.
16MB on Motherboard and normal 2MB Chip. So, there is plenty of FAST RAM. But 3.1.4 is using FAST RAM a lot more than 3.5 did..so it's much quicker...at least I can see the speed difference. With PPC DataTypes (etc..) used, there's a little bit more of a boost in speed.

[sigma63]

Originally Posted by AC/DC HACKER!

I have to reboot, hold the mouse buttons get New Amiga Boot Menu (cool change!), and then click Boot (with S-S)...

What do you mean by cool change?

I didn't notice any change at all.

[esel]

If you have AGA you can use enter to switch it to 31 KHZ

[AC/DC HACKER!]

Originally Posted by sigma63

What do you mean by cool change?

I didn't notice any change at all.

That's a regional expression, in the States. It means "I like what I see, I'm in agreement with it." - You don't notice a change at the Top Right?

[sigma63]

Originally Posted by esel

If you have AGA you can use enter to switch it to 31 KHZ

Ahh, OK. That was my bad, i've looked at it with a non-AGA-Config
Thanks for the hint.

[sigma63]

Originally Posted by AC/DC HACKER!

That's a regional expression, in the States. It means "I like what I see, I'm in agreement with it." - You don't notice a change at the Top Right?

Hey AC/DC Hacker, thank you for the reply.

I think we talked past each other. I could image what you mean by cool change, but i just didn't notice any change at all. Reason: it was a non-AGA-Config i'm working with

Now i realize the Text: "..., press RETURN for 31kHz modes)"

BTW: are you the one at the total-commander-forums?

[bubbob42]

Hyperion has now released a Bonus icon package created by Martin "Mason" Merz. It contains icons for many popular applications in the AmigaOS3.1.4 GlowIcon style.

Registered buyers can find it in their personal download section on the Hyperion website as a free addon.

Attached is a little preview. Thank you, Martin!

[indigolemon]

Downloaded the new icons this morning, they look great

I have a small question around workbench.library. I've used parts of 3.1.4 to update my existing 3.9 installation ( which has worked great, thanks in no small part to a handy script I used a reference ).

Before I start, I'd like to say this is in no way a complaint, and I'm also very aware I now have an oddball hybrid system - and therefore fully expect this issue may be entirely my fault

So - the only snag I've hit with the new libs etc is related to workbench.library 45.194. I have various arexx scripts in the tools menu which I've become used to using - for example 'Make real icons' and 'Edit text file' invoke 'CreateDefaults.rexx' and 'Edit.rexx' respectively.

Neither of these scripts seem to work anymore with 45.194, but if I go back to 45.137 they are fine. Is the arexx support in the new lib different in some way?

[daxb]

Originally Posted by indigolemon

Neither of these scripts seem to work anymore with 45.194, but if I go back to 45.137 they are fine. Is the arexx support in the new lib different in some way?

I was told that the Workbench ARexx port hasn't changed. So I would would put "trace i" (on top) in one of the scripts and start TCO (opens a trace console). Then start the script and see if there is any (error) output. Or try SnoopDos. At least do something to track down the fault. For example: Do the scripts work if launched from Shell? Can the scripts found?

[Olaf Barthel]

Originally Posted by indigolemon

Neither of these scripts seem to work anymore with 45.194, but if I go back to 45.137 they are fine. Is the arexx support in the new lib different in some way?

What has changed is that the ARexx port of Workbench now uses the updated rexxsyslib.library to read, set and modify script variables instead of the old RVI ("rexx variables interface") link library code.

Please check if the rexxsyslib.library installed on your system is the version which came with the updated workbench.library.

[Olaf Barthel]

Originally Posted by AC/DC HACKER!

Excited to check the new update. Also, wondering, is a GUI planned? Appreciate the reply.

I'm not so sure about the GUI idea yet. The new Disk Doctor is already a very large program compared to the other tools and utilities on the Workbench disk set. A GUI would not make it shorter

The next development step (as far as my own planning is concerned) would be to finish work on the repair operation to complement the existing examine and copy/recovery operations.

The repair operation would attempt to restore the volume to consistency. That is, it would return the volume to validated state, rebuild directories as needed (including the directory cache information which gave DCFS its name) and remove all the files and directories which are damaged and cannot be repaired.

As with the copy/recovery operation, you would be able to preview which changes Disk Doctor would make to the volume. Repair operations would have to be confirmed before they are made.

If the volume cannot be repaired Disk Doctor would say so and refuse to perform the operation: you would then need to rely upon the copy/recovery operation to salvage the data.

All of this will make an already large program even larger. So maybe the future of the new Disk Doctor lies somewhere in splitting up the single program into a set of which one can examine, one can copy and one which can repair. After that, maybe there's going to be a GUI involved.

For now I reckon the new Disk Doctor may have to be what it always was: a tool of last resort when everything else has failed. Such tools are never nice and rarely comfortable, but I did try to get close to this ideal with the help of everybody who tested the Disk Doctor and provided feedback on usability (or rather the lack thereof).

[indigolemon]

Originally Posted by Olaf Barthel

What has changed is that the ARexx port of Workbench now uses the updated rexxsyslib.library to read, set and modify script variables instead of the old RVI ("rexx variables interface") link library code.

Please check if the rexxsyslib.library installed on your system is the version which came with the updated workbench.library.

That was exactly the problem, thanks! All working great now.

Knew it would be my fault

[DanyPPC]

Originally Posted by bubbob42

Hyperion has now released a Bonus icon package created by Martin "Mason" Merz. It contains icons for many popular applications in the AmigaOS3.1.4 GlowIcon style.

Thanks for advice, downloaded

Thanks also to Martin for this icon pack.
I am very satisfied with this OS for my A1200/030.