Watch files or How to stop corrupted prefs

Is there a program that can watch files for write access and log those?

I have an annoying case of a corrupted prefs file.
It happens when a program crashes (not a specific one, just any program crash.
It happens randomly on a simple reboot (fast, hard, sync or not doesn't matter)
It happens a fter some down time on simple boot.

I KNOW that it does NOT happen on startup/boot, but right before WB goes to reboot or a program crashed...i know that because i tried locking WB at first command in startup-sequence and unlocking it after all programs were up.

I could read protect the file, but then i
a) wouldn't be able to change/save the prefs without the extra step of making the file writable again
2) wouldn't see which program tried to corrupt the file (as i only get the warning that the file is write protected, but not from which program)
d) couldn't gather information about the culprit and in turn violently delete the corrupting piece of dead-bits

Is there such a program

...oh, and if anyone has the same problem, please share...for me it's ENVARC:Sys/ringhio.appsprefs.xml that randomly ends up with a corrupted prefs file (together with a window on boot telling me that line xxx has some error or something, also not even with the information of what programs sends the error)

I know it's ringhio because i created a backup and i use custom sounds which always gets set back to that stupid harp (i can't hear anymore)

Thanks

@Raziel

Would WaitNotify on OS4Depot be what you need ?

@BillE

Unfortunately not.

While it's an interesting concept the program is aimed towards script usage.

Also, the output possibilities with "More" are limited to the changed files contents, which i don't need, i need the name of the program that does the change/corrupts the file, e.g. MultiEdit/Notepad for a test.

I'm going with "protect -wd" as a workaround for now, annoying but at least i can work without always having to change my settings back.

Keep the hints coming, though

@Raziel

Maybe you can use snoopdos and see if it tracks it or get any hints

@Marko

That wouldn't work as it seems to corrupt/write to the prefs once i let it reboot.

Maybe the "sync" option and the fact that it closes some programs (is Notification part of them) leads to writing to the prefs and corrupting them?

@Raziel

Is something installing a reset-handler which maybe writes to the file but doesn't finish writing quick enough (or it ends up in memory cache rather than on disk and reboots before sync)

Not sure if it's possible to find out which reset-handlers are installed.

@Chris

I'm using a reboot command (not sure which one) which has a sync command attached to it.

Problem is that randomly it also corrupts the prefs file on a crash of random programs.

Annoying

@Raziel

I'm not sure why you need a sync - just wait for disk access to finish and it should be fine. Presumably the sync is what is screwing it up.

For example use a different reboot command and something like this (don't know if it works on OS4 but the source is there): http://aminet.net/package/util/boot/ResetHandler

@Chris

I need to check which reboot program exactly I'm using (I keep losing track of such details since I tend to automate anything with scripts nowadays.)
In any way, if the sync switch is screwing things up, it's a bug in the program and need to ge resolved imho

@Raziel

Quote:Maybe it's simply the default C:Reboot? It has a SYNC option.

If it is, you could try, instead of the SYNC, to use e.g. WAIT 5.

That should normally give enough time for write operations to finish, so the reset is less likely to cause problems.

Edit: BTW, the SYNC option in C:Reboot does not (as per my understanding) notify any programs or similar, it just inhibits all volumes, so they can't be written to.

Best regards,

Niels

@nbache

Probably, that could be it then.
Maybe im just unlucky in the prefs file being written to while the drive gets locked?
Then again, that would be extremely coincidental while happening nearly all the time...

Will check the wait option.

Thanks for the hint

@Raziel

If it works as nbache says, then the sync might be blocking the drive and then the reboot happens, but due to timing the inhibit may not be completely done. If Ringhio has added a reset-handler which saves prefs on reboot then that could cause it to half write the file before the drive is protected. Result - corrupt file.

I don't see the need for sync, take it out.

@Chris

Will try when im back home, thank you

@Raziel

Slightly late to this thread but you can use my Activity monitor to monitors files and directories for changes.

http://os4depot.net/?function=showfil ... /misc/activitymonitor.lha

@Chris

Quote:

Mr Solies excellent Ranger utility has a exec->Resethandlers tab

@Raziel

Didn't read this bit before..

Quote:

What version of Notifications are you using? I fixed a race condition with prefs reading code that might cause arbitrary corruption in the prefs file (or at least make it seem corrupt when it wasn't)

@Chris

Quote:

Notifications Server does not do that.

@broadblues

Thank you.

Will test, check and report back when i get back home

@all

Removed teh SYNC option but i immidiately got a corrupted prefs on the next reboot

This is what i'm getting after a corruption:
Parse error at line 276:
unclosed token

The reboot commandf i'm using is
version c:Reboot file full
Reboot 54.1 (10.07.2015)

I'm going back to manually locking the prefs file with protect

@Raziel

Same version of C:Reboot as mine.

You didn't state the version of Notifications you're using? broadblues asked about that a couple of posts ago (and I'm curious too).

Best regards,

Niels