Spurious write permission error

[C E Macfarlane]

Please see below ...

www.macfh.co.uk/CEMH.html

>     -----Original Message-----
>     From: artisticforge . [mailto:artisticforge at gmail.com]
>     Sent: 03 May 2016 14:49
>     To: c.e.macfarlane at macfh.co.uk
>     Cc: Nick Payne; get_iplayer
>     Subject: Re: Spurious write permission error
>     
>     hello
>     
>     First a request. can you refrain from inserting your web page with
>     every post? it is annoying

Tough shit.  It's my standard email sig, and I'm not changing it just for you.

>     second, I do not do "Windows". That said, any operating system should
>     prevent the deletion of a file that is in use.
>     MacOSX & Linux will not let me delete a directory if that directory is
>     the "current working directory" for a process.
>     The test of WMP would only prove that the programmers were lazy and/or
>     just plain sloppy.

You appear not to have noticed that these programmers work for the same firm that writes the OS!  No more need be said!

[snip irrelevancies]

>     The operating system is not going to allow N different processes
>     access the same resource at the exactly the same time. Not going to
>     happen. 

Indeed.

>	So the chance of N GiP all going for a write append to the
>     download_history file at the exact same instant in time is ZERO.

In theory, it rather depends on how you define 'instant in time', in practice, it's just plain incorrect.  It is sufficient for contention to occur that a first process wants access to a file, as it is the first to request this access will be granted, and it is still updating the file when a second reaches a state where it requests access to the same file, and the second request times out and is denied, generating an error message.

>	The operating system is not going to allow it to occur.

Exactly, so an error is produced.

>	The requests will
>     all go into the queue and processed in order.

NOT TRUE!  This is the root of your misunderstanding.

>     What you have been describing all along is a "Race condition".

No, a race condition is when one process has locked a resource and for some reason cannot or will not unlock it, while a second wants access to that resource, but doesn't abort gracefully when it can't gain access to it, and keeps endlessly retrying.  That is not what is happening here, if it was one or more of the GiP instances would just hang indefinitely, whereas in fact they are correctly aborting with an error message.

>     Concerning "Computer Hiccups", events of unknown causes, I have been
>     around enough years to say that "Stuff Happens"
>     which can never be explained. A Flipped bit, a random byte, etc.
>     Nothing is prefect and "Stuff Happens". Those random bit that go bump
>     in the night.

By Occam's razor, the simplest explanation is the one that I've given, so we don't need to invent any paranormal ghosts in the machine.