AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks

[kolla]

Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Any system that lacks a functioning RTC, which I believe is vast majority of Amiga systems.

[kolla]

Why is the output of a script running on a German system non-meaningful if it appears in German?

Context.

Just because I have Norwegian locale (which Hyperion says I MUST use to stay license compliant, despite the cringing quality of the locales) does not mean I can not be in non-Norwegian contexts. We live in a reality where one cannot expect everything to be localised correctly, for many of us the correct locale does not even exist, and most of us are not mono-lingual. In SYS:Prefs/Locale can set up a prioritised list of languages, and this can lead to programs/scripts having mixed language output, which can be both entertaining and confusing.

[kolla]

Why does that cause any problems right now?

How do you list the timestamp of DH0: ?

In OS 3.2, what is the output of "List FLAT DH0:"?

[kolla]

The correct answer is then to localize the script.

I often do, but locales for my preferred native language do not even exist, so it becomes neo-norwenglish.

[kolla]

In OS 3.2, what is the output of "List FLAT DH0:"?

For example like this. The directory name is "" (empty) and the time stamp is the time stamp of the root.

For example what? Nothing?

Code: [Select]

Directory "" is empty

[kolla]

The time stamp is taken from the creation date of the volume, which is in the root node. The creation date is not adjustable.

So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

ACTION_SETDATE adjusts the modiifcation date of the node, and by that also that of the root node.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas

Frankly, why do you care? You just said you don't accept the license, so don't want to buy the license, yet bought one.

That is an entirely different problem, which I just explained in a different thread - the license was not presented to me at point of sale - I very much expect the license to change in the future, perhaps even for OS 3.2.

Hyperion is, after all, run by a lawyer, and "legalese" is the only form of communication that works.

[kolla]

Moving on from the trolling attempts by the head OS developers... what can be done to improve the system time problem with Amiga systems that have no RTC?

First some goals:
* system time must as much as possible go _forwards_, even between reboots, warm and cold.
* there are situations when going backwards is unavoidable, in such cases, the "amount of time" going backwards should be kept as low as possible

My suggestion is inspired by TimeKeeper and getting timestamp for boot filesystem

One part is placed in kickstart (in existing or new module, why not systemd.. I mean System-Startup), if no functional RTC is found...

* check if a certain address space in chipram contains a valid timestamp, and set system time accordingly
* if no such valid timestmap is found, allocate an address space, it and make it warm-boot resident.
* Continue as today, take timestamp from boot filesystem, but rather "modified" timestamp rather than "created" timestamp.

Second part is "running code", it would be preferable if it too was in kickstart, but if not... something that "always runs", IPrefs is a candidate, and its job is simply to
* if dedicated address space in chipram exists, steadily and frequently update it with current timestamp.

This should keep system time going forward, and updating system time to a more "current" one is a matter of adjusting it manually or via NTP, GSM over serial port or whatever, and then just doing any kind of modification to boot volume - for example "SetDate DH0:"

[kolla]

So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

You cannot avoid that.

It can be avoided to a much larger degree than what is the case today.

Leaving compatibility issues aside

Can you think of any?

Is there any filesystem that Amiga can boot from, that does not have a root node to get system time from?

Do all filesystems that Amiga can boot from currently, all have a creation timestamp to get system time from?

touching a file only "bubbles up" one directory level (i.e. changes the change date of the containing directory), but it does not bubble up to the root level.

I know that, and nowhere did I imply that _any_ change to a filesystem would change the root node - that was not the point.

That is, without doing a full tree search of the boot disk, you cannot prevent that a file has a change date in the future of the root directory.

Very true - but again, that was not the point.

The point was to have the *boot system time* moving forward (albeit slowly), and to make it *easy* to bump up boot system time.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

Though it is probably a bad idea to change this

Because... anything specific you can think of?

 

besides, it would only be a change if the FFS is used to boot the system. For some bizarre reason, it is the boot file system that sets the system date.

I don't think it is so bizarre, really. Would it be less bizarre to always start in 1978-01-01 00:00:00?

What other file systems do is up to them - but there is no interface (DosPacket) to adjust the creation time of a file system, and inventing one would not improve the situation for any other file system.

Exactly - do all filesystems even have a creation timestamp?

The check for timestamp on the boot filesystem could have a prioritised list...
* check for the presence of a magic file in the root of the boot filesystem (I use :.timestamp myself)
* check for the presence of a modified timestamp on the root node of the boot filesystem
* check for the presence of a creation timestamp on the root node of the boot filesystem

[kolla]

I don't see the benefits of this.

Well, I do - am I alone?

As you say, it is a matter of finding a time source at boot - a functional RTC is the best option, a user maintained timestamp (in memory, or file) is a good second, timestamp from root node of boot filesystem a bizarre third...

The most important is that system time should, as much possible, survive warm boots.

[kolla]

<crickets>

I suppose this means that if OS 3.2 actually will incorporate some of my ideas (it already has), you will be utterly against it?

Or are you just OK with _ANYTHING_, as long as it comes from Thomas?

[kolla]

Next up, a silly bug - or feature, depending on how you see it. C:Relabel, it is for relabeling volumes (devices, filesystems, partitions, whatever you like calling them), for example “relabel RAM: Memory”. However it doesn’t validate that the argument given is actually a volume/device/filesystem/partition etc or an assign, and this has the funny result that the root device (...) that the assign primarily points at, is relabeled, instead of printing an error message. For example “relabel T: Temp” will on a default setup relabel RAM: to Temp.

Feature? Bug? Nobody knows.

[kolla]

On the topic of BOOPSI - whatever happened to the tabs.gadgets and the others from v42?

[kolla]

A simple example of how one can bundle "apps" on Amiga.

http://kolla.no/Bear.lha

[kolla]

So with OS 3.2 it will at last be possible to get the volume label from a device, by using "List DEV: FLAT LFORMAT %F", but it will still have the trailing colon behind the volume label.

I suggest a small change to C:Relabel so that "DRIVE/A, NAME/A" becomes "DRIVE/A, NAME", and if "NAME" is omitted, the current label is printed out.

(and why not rename it from "Relabel" to just "Label" while at it)

[kolla]

@kollaI've always wondered why you don't join / are not on the OS3.X devs team in the first place? 

Because it would require me to sign a nonsense contract with people I don't want to be associated with.

[kolla]

Try the which command to get volume name from device:. Unfortunately, before 3.2 it is bugged and doesn’t work if the root of the device doesn’t have +e or +s bit set.

Huh, that looks more like an unintended bi-effect of a bug than an actual feature...