Amiga history: Why was "Disk doctor" so spectacularly bad at its job? Here is why...

[kolla]

Speaking of file systems...
* when booting, if no RTC is available, the OS will set system time to the creation time stamp of the filesystem from which it boots  - very clever, if only there was a tool to adjust and update this time stamp
* OS4.1 comes with a newer version of FFS (FFS2?), with long filenames (0x444F5307) - is there a filesystem handler for OS3.x that supports this?

EDIT:

Oh, to stay somewhat on topic - DiskSalv rarely solved much for me, however, I have seen QuarterBackTools perform miracles

[kolla]

Actually it's even weirder - the default ROM file system reads the volume 'last altered date', and if the system time happens to be unset, will change it to that date.

The way the default file system works, it should be sufficient to change a file on the volume. That change will bubble up to the root directory, and it should replace the 'last altered date' unless that change came with a time stamp which preceded what's already recorded in the root directory.

Are you really sure about this?

I ask because that is not at all how I experience it, for me it looks like the time of formatting, and not 'last altered', is used. I typically keep a loopy script update a .timestamp file regularly, and doing that alone does not work.

Of course there is  I wrote it, starting in 2001, for use on AmigaOS 2.x/3.x. This is still the most complex and challenging software I ever wrote. The AmigaOS 4 and MorphOS versions are ports of the original 68000 implementation. I still use the 68000 version to this day on my A3000UX development machine at home.

Right, and of course.

Turned out my problem was not FFS at all, it was really a partition with SFS/02, that didn't show up in OS3.9 - not FFS with long filenames. I had forgotten to add SFS/02 to RDB. This is my A3000 that multiboots between OS3.9, OS4.1 and Morphos 1.4. I am pondering on moving back to FFS as I keep getting random errors from SFS about not being able to read blocks (750GB ATA drive with ACard IDE-UW SCSI). It's sadly not so easy to find a filesystem that one can rely on for all the different "flavours". Also, I hope Amiga filesystems will improve so that they transparently can deal with bad-blocks, bit-flips etc, as all such errors become statistically impossible to avoid on large drives.

[kolla]

Code: [Select]

setdate dh0:
It should just work

[kolla]

Apparently, the only way to advance the "last altered date" field of the root directory is in making a change to the file system which has the effect of allocating/releasing storage space.

Allright, I will test this later tonight, and change my loopy script to something like this...

Code: [Select]

set timestamp sys:.timestamp
lab loop
if exists $timestamp
  delete $timestamp quiet force
else
  echo to $timestamp
endif
wait 60
skip back loop

I cannot help laughing at this silly workaround :laughing:

[kolla]

Allright, I have done some testing and conclude how this works on my MIST, which has no RTC to speak of, using FFS 45.16 (if I recall correctly).

When I boot without startup-sequence, the date is 11-Oct-09 03:14:16, which I guess was the time I originally installed this fileystems on the Minimig. I agree that it is somewhat funny that the date is 11-10-09 followed by a clock that looks strikingly similar to pi

There is a SYS:.timestamp there, and if I do this:

Code: [Select]

assign T: RAM:
date `list sys:.timestamp lformat "%D %T" dates`
the system time is set according to what the timestamp of that file is (in my case 16-Sep-17 16:40:15).

According to above speculations, it should now simply be a matter of deleting the sys:.timestamp, and the "last date altered" of the filesystem should change. And maybe it does, who knows... I don't know of a operating system tool that can actually read the mentioned timestamps of a filesystem. What I do know, though, is that a reboot sends me back to 11-Oct-09 03:14:16.

So, it appears to me that adding and removing files to the root of the filesystem has no effect on the timestamp of the filesystem that is used to set system time on boot, or that something else goes on. Also, relabelling sys: had no effect on system time after reboot.

[kolla]

Just to spin on this a little more, though a bit off-topic - how I keep system time without battery backed RTC - I use this wonderful little gem: http://aminet.net/package/util/time/TimeKeeper and I have many times wished that it could be built into a rom module, so that system time could be kept through reboots without the need of running a program from startup-sequence. Just an idea