NGFilesystem file corruption

[Radek]

Is there anything that ordinary user can do about that, i.e. opening file manually and saving it? Is it possible with cookies?
Other nuisance is caching fonts every time i open Odyssey, is it due to the same issue as with cookies?

[broadblues]

In that case I shall be using SFS2 instead
I already expressed my opinion in a private email.

You can get similar problems here, maybe just less often. The only safe solution is to quit oddysey before rebooting, so that it closes all it's file handles. Also make sure that background processes have quit, odyssey has a fair few (though not as many as Timberwolf)

EDIT: With reference to item 2 in your post: I used Snoopy to check what IO functions Odyssey is using. It's using unbuffered AmigaDOS 'Read' and 'Write' commands for cookies so I don't think there's any flushing to be done.

There more than one kind of flushing data, whilst these SQL files are open the data is not 100% guaranteed ro be valid on disk until they are closed by the application.

[broadblues]

Is there anything that ordinary user can do about that, i.e. opening file manually and saving it? Is it possible with cookies?

Close the program down before rebooting.

Other nuisance is caching fonts every time i open Odyssey, is it due to the same issue as with cookies?

No this is due to a cache file withy long file name in the font cache directory which never correctly overwrites the old name.

Fix it by deleteing the files with long names made of numbers and letters in Conf/font/ and then on the next run the cache with be recreated but runs after will be fine. (until you add a new font to the system)

[xenic]

Close the program down before rebooting.

Maybe that's good advice for an OS that never crashes, freezes or loses USB IO but not for OS4. While working out problems on my new X5000 (USB failures on boot, sound card caused freezes, etc.) and resolving those issues, I had to deal with constant cookie file corruption because of required reboots. If you also read the NGFilesystem topic in the X5000 forum you will also note that this might affect other SQL based programs too. I haven't checked but other files in the Odyssey directory might be going corrupt on reboot too.

How is the user supposed to know what programs, background processes and commodities might keep a file open instead of constantly opening and closing the file?? It might be interresting to see a poll of how many OS4 users have never had a system or USB IO freeze. My guess would be exactly zero. Tony has told me that NGFilesystem will not be changed to eliminate this problem so it's a moot point anyway. I've started switching my partitions to SFS2 so I won't be worrying about this problem anymore.

If an unchanged NGFilesystem is released for all OS4 hardware I expect you will see a lot of complaints.

[daveyw]

Thanks to xenic's help, I can now confirm the behaviour. It is caused by the fact that NGFS "writes behind" its meta data. File data is written immediately, but meta data (eg the file header, containing the file size) is not updated until the next write or the file is closed.

Is this why the partition create date always shows the date/time you booted, rather than the actual date you created the partition?

[tonyw]

No, the partition data is only written once, during Format, and it's the time/date of the Format. If some program shows the boot time, it's not coming from there.

[xenic]

No, the partition data is only written once, during Format, and it's the time/date of the Format. If some program shows the boot time, it's not coming from there.

Not sure where daveyw got his date but on my system 'Ranger' shows the creation time/date for SFS2 partitions and the boot time for NGFilesystem partitions. Maybe Ranger just needs an update.

[broadblues]

No, the partition data is only written once, during Format, and it's the time/date of the Format. If some program shows the boot time, it's not coming from there.

Not sure where daveyw got his date but on my system 'Ranger' shows the creation time/date for SFS2 partitions and the boot time for NGFilesystem partitions. Maybe Ranger just needs an update.

I see the boot date in the icon information (RAWBinfo) window for NGFS partitions. Not something I've noticed before. I'l chack for BZ and raise one if nothing is found....

[tonyw]

Yeah, so it does. Don't worry about the BZ, I'll find out why and fix it.

[colinw]

Yeah, so it does. Don't worry about the BZ, I'll find out why and fix it.

Don't quote me on this, I probably should investigate first, but I have better things to do on a saturday morning,
I think that RAWBinfo just looks at the volume node datestamp and shows that in the info window and makes
the assumption it was when the volume was formatted.

So, technically, since the volume node is "created" at each boot, you are technically correct in showing the
boot datestamp, however, what I think the others do, (I probably should look at those too, but...)
is just copy the volume node datestamp from the "Serialize()/Format()" datestamp each mount, and use that.

It doesn't really matter, it still makes the volume unique because you can't have two volumes formatted
and Serialize()/Format()'ted at exactly the same time, (unless someone clones it), so the case-insensitive
duplicate name conflict rules for volumes will still work, as long as the two datestamps differ.

However, I think the users would prefer the volume datestamp to reflect when it was Serialize()/Format()ted.