On Fri Jul 30 10:11:24 2021 "Thomas Schmitt" <scdbac...@gmx.net> wrote:
> to...@tuxteam.de wrote:
>
>>> While I've read about issuing sync *twice* with the explanation
>>> that sysadmins are a supersticious bunch
>
> Polyna-Maude Racicot-Summerside wrote:
>
>> I'm really asking why do it 3 time.
>> In case it came back to the prompt *before* finishing to do it's job
>
> I dimly remember that it was part of the shutdown procedure of one
> of the earliest Unix machines which i met. IBM RT, Apollo DN3000, > >
> microVAX ... ?
> The shutdown spell was something like
>
> sync ; sync ; halt
>
> Googling "sync halt" leads me to an interesting theory at
> https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
>
> According to section "That sync; sync; sync Thing..." two bugs of
> early systems' sync existed (one explored by the blog's author,
> one as rumor):
>
> 1: The sync system call returned without waiting.
> Workaround:
> Keep the human operator busy while the machine is still not done
> with flushing buffers. E.g. prescribe to type three lines of
> "sync" before typing "halt".
>
> 2: Only the first sync call returned early, whereas the second sync
> properly blocked until flushing was done.
> That seems to be the origin of my memory.
I fed "multiple sync commands" into DuckDuckGo, and got the
following hit, which is even nicer:
https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync
Basically, the act of typing three sync commands, each on a
separate line (as opposed to "sync ; sync ; sync"), gives the
system enough time for the first sync command to do its thing.
Or, as Tony Orlando once sang:
Sync three times on the console if you want me.
Close all the pipes if the answer is no.
Just remember, things could be worse - and if Microsoft
is involved, they usually are. I first noticed a "feature"
in Windows 95 which persists to this day: requests to delete
a file are queued, and done when Windows gets around to it.
This means that if your program issues an unlink(), the
file might still be there when the call returns. Thus,
the old trick of updating a file by copying it to a work
file while making changes, deleting the original file, and
renaming the work file to the original file's name runs the
risk of failure if the deletion doesn't take effect before
the rename, which will then fail. It doesn't happen often,
but if you have a program that's run daily by a couple of
thousand users, even a .01% chance of failure means that
your support staff will get several anguished calls a week
from customers who have lost critical files. (It happens
with batch files too.)
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
