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?
NGFilesystem file corruption
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: NGFilesystem file corruption
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)In that case I shall be using SFS2 instead
I already expressed my opinion in a private email.
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.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.
Last edited by broadblues on Thu Aug 17, 2017 6:56 pm, edited 1 time in total.
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: NGFilesystem file corruption
Close the program down before rebooting.Radek wrote:Is there anything that ordinary user can do about that, i.e. opening file manually and saving it? Is it possible 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.Other nuisance is caching fonts every time i open Odyssey, is it due to the same issue as with cookies?
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)
Re: NGFilesystem file corruption
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.broadblues wrote:Close the program down before rebooting.
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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: NGFilesystem file corruption
Is this why the partition create date always shows the date/time you booted, rather than the actual date you created the partition?tonyw wrote: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.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: NGFilesystem file corruption
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.
cheers
tony
tony
Re: NGFilesystem file corruption
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.tonyw wrote: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.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: NGFilesystem file corruption
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....xenic wrote: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.tonyw wrote: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.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: NGFilesystem file corruption
Yeah, so it does. Don't worry about the BZ, I'll find out why and fix it.
cheers
tony
tony
- colinw
- AmigaOS Core Developer
- Posts: 207
- Joined: Mon Aug 15, 2011 9:20 am
- Location: Brisbane, QLD. Australia.
Re: NGFilesystem file corruption
Don't quote me on this, I probably should investigate first, but I have better things to do on a saturday morning,tonyw wrote:Yeah, so it does. Don't worry about the BZ, I'll find out why and fix it.
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.