Spurious write permission error

[artisticforge .]

hello

First a request. can you refrain from inserting your web page with
every post? it is annoying

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.
I use VLC or iTunes. 99.99% of the time it is iTunes.

I have 1 Toshiba laptop with Windows 10 installed. It sits in the
corner turned off until the rare event where i need to use
windows for something. Which are becoming more rare with each passing
day. I do not think it has been on this year.

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. 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. The
operating system is not going to allow it to occur. The requests will
all go into the queue and processed in order.

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

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.

I have farm fields that need tending and firewood that needs to be
cut. the tractors do not drive themselves, at least not yet.
So enough of this diversion.


On Tue, May 3, 2016 at 7:26 AM, C E Macfarlane
<c.e.macfarlane at macfh.co.uk> wrote:
> Please see below ...
>

>>     -----Original Message-----
>>     From: artisticforge . [mailto:artisticforge at gmail.com]
>>     Sent: 03 May 2016 12:27
>>     To: c.e.macfarlane at macfh.co.uk
>>     Cc: Nick Payne; get_iplayer
>>     Subject: Re: Spurious write permission error
>>
>>     Race conditions as you suggest
>
> I never mentioned race conditions.  If race conditions were encountered, at very least Task Manager would have to be invoked to end each process involved in the race, perhaps even the computer rebooted if the race hogged so much CPU that TM could not be invoked.
>
>>       would be the fault of the operating
>>     system and/or filesystem design.
>>     Nearly every operating system has drivers which queue requests so that
>>     there is no chaos in the allocation of resources.
>
> Yes.
>
>>     A design flaw that glaring would relegate the operating system to
>>     nothing but a toy and the operating system would never
>>     be used in a commercial environment.
>
> Here's a test for you ...
>
> Open a file to play in Window Media Player, but then press the stop button so that nothing is actually being played.  If you like, <rt-click> another media file and choose to add it to WMP's current playlist.  IME, even though WMP is doing nothing with either file, commonly both are now locked, and cannot be deleted, renamed, or written to, or, if they are appear to be successfully deleted or renamed, examination of the directory shows that they have not been, and won't be until WMP is either exited or the files are deleted from its current playlist.  Sometimes, if a file gets updated when within WMP's playlist  -  say if you use the back button to go to the previous playlist, then update a file in the current playlist by, say, re-extracting it from a longer file with slightly different start and stop time parameters, then use the forward button to return to the current playlist, WMP gets hopelessly confused, and tries to play the new file as if it were the old, and aborts with an error message, rather than simply realising that the file has been updated, and refetching its vital statistics from the new version of the file and carrying on from there.

>>       They are looked at at start up , at which point they are
>>     "sucked into" memory
>>     to be used. The download_history file is opened for append writes
>>     after a file has been downloaded . Does not mean that the file has
>>     been downloaded correctly just that it has been downloaded.
>
> Yes, so, as I suggested, if two instances happen simultaneously to finish downloading their respective programmes, contention could occur when they try simultaneously to update the download history accordingly.
>


-- 
terry l. ridder ><>