Dissapearing files and files not saved

[Piru]

@ChaosLord

Turn OFF your PFS3 write cache.

There is no way to turn off the write cache in PFS.

The write cache is totally unsafe.

BS.

[AMC258]

I have never found a way to get around this problem.  It does happen on every hard drive I've ever used with PFS3.  It does not make PFS3 not worth using, AT ALL!

You just have to give your Amiga a minute or two before you reboot it.  It's still less painful than rebooting a peecee.

[Piru]

@AMC258

You just have to give your Amiga a minute or two before you reboot it.

You need to wait 3 seconds, or have some app send ACTION_FLUSH to the handler, flushing any pending writes immediatelly.

Hardly a real problem, you just need to be aware of it.

[Amigaz]

Gonna switch to SFS on my Workebench partition since the other partitions aren't acting weird

I just think it's odd that this symptom is so severe on this setup...I guess Framiga is right also, it's an old IBM 4 gig SCSI drive

[AmiKit]

Piru wrote:

You need to wait 3 seconds...

Yes, waiting the 3 seconds before reboot always worked for me with PFS3 harddrives.

[ChaosLord]

Theory:

Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs.  Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.

Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS.  Yet other people such as Piru swear that PFS is 100% reliable.  So there must be something different between your system and Piru's to cause this problem.  If you figure out what is different then you will find the problem and permanently alter the course of Amiga history forever more.

[Amigaz]

ChaosLord wrote:
Theory:

Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs.  Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.

Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS.  Yet other people such as Piru swear that PFS is 100% reliable.  So there must be something different between your system and Piru's to cause this problem.  If you figure out what is different then you will find the problem and permanently alter the course of Amiga history forever more.

Something evil was sure causing it  :-P

Just switched to SFS on the "evil" partition, it works so far..let's so how long...if it starts acting up again I'll bin the harddrive for sure

Not using any fancy sys hacks just Blizkick with some "safe" modules which I'm using trouble free on my other Amiga's  ;-)

[Mark]

Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs. Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.

Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS. Yet other people such as Piru swear that PFS is 100% reliable. So there must be something different between your system and Piru's to cause this problem.

Never underestimate the ability of reckless users to not wait at least five seconds after a write before rebooting or turning off their Amiga.  It happens all the time.

In any event, there is at least one hack that causes problems similar to this no matter how long you wait; DiskSafe.  Version 1.14 of DiskSafe causes copies involving many files at a time to fail silently without setting a return code.  This happens with the shell copy command and with copies done by Installer.  I don't recall if using Workbench to drag a drawer from one partition to another also failed, and I never tested multiple deletes.  This was discovered on an A3000 using AmigaOS 3.1 and FFS.

[nyteschayde]

Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm

@AMC258

You need to wait 3 seconds, or have some app send ACTION_FLUSH to the handler, flushing any pending writes immediatelly.

Hardly a real problem, you just need to be aware of it.

[kolla]

There are some reset handlers that can postpone reset up to 10 seconds when ctrl-a-a is pressed, some of them allow execution of commands or scripts too, but the case of pfs, just the 10 seconds wait should be cool enough. One such reset handler is kbd, written by an old friend of mine a long time ago

http://aminet.net/package/util/boot/KBD

[paul1981]

Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm

This is for PFS3 right? Some of my Amigas do use PFS and when you write to the disk there is definitely a delay before the HDD light illuminates, probably 2-3 seconds as said. People should just be more aware that if you write to a disk then you should wait for the HDD light to illuminate and then deluminate before turning off. There have been times when I've forgotton this myself and thought 'what the hell? Where's my edits to the Startup-sequence?' :lol:

I use SFS too. Never have I ever seen missing dirs or files or any such strange magic on my Amigas. ChaosLord (God bless him) may have been onto something though regarding the software environment and all, should there actually be a problem with PFS that is, and not the users...

[guest11527]

Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm

DiskSafe does this for you. Note, however, that ACTION_FLUSH does not write out data immediately under FFS versions prior to 3.9. This particular bug was fixed, and DiskSafe includes a workaround for older versions.

What was stated above ("Disksafe invalidates copies") is something that would really surprise me because I'm using it on a daily basis. If you have a copy running, of course, and *then* reset the machine while the copy process is in progress, it will clearly abort the copy operation. That's the point because otherwise the copy might be aborted the hard way and the system could reboot before the copy is finished.

[kolla]

DiskSafe does this for you.

I notice that if I run LoadModule to load a module, and have workbench up and running, the icons for all the disk partitions turn into "NDOS" like icons for a brief moment before the system resets. Is this a similar "sync" like thing going on? And if yes, would it not be neat with a C:reboot that would do the same?

[guest11527]

Is this a similar "sync" like thing going on?

Yes. DiskSafe first forcibly (sp?) closes all files, sends an ACTION_FLUSH to the file system, then waits for the file system to shut down motors (as a work-around against FFS versions < 44 ACTION_FLUSH not being synchronized as it should), then inhibits all file systems listed.

Ideally, this should really be part of a file system function (ACTION_SHUTDOWN or something like it), but it isn't.

And if yes, would it not be neat with a C:reboot that would do the same?

If the reboot goes through exec/ColdReboot(), then this is exactly what it does. ColdReboot() is patched to a small function which signals DiskSafe to take over and shut down the machine instead.

If, however, C:Reboot simply runs into a RESET instruction, then there is nothing I can do. It probably won't work in first place on a couple of machines anyhow. The reset instruction resets the external hardware, but not the CPU.