Please see below ... www.macfh.co.uk/CEMH.html
> -----Original Message----- > From: artisticforge . [mailto:[email protected]] > Sent: 03 May 2016 12:27 > To: [email protected] > 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 er ror 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. ... so your nice well-behaved picture of how an OS and the software running on it should behave just doesn't always happen in practice. > Having read and studied the GiP Perl code over the years, no where in > the code are any cache files nor the download_history file opened and > kept open. I never said that they were, merely that different processes might attempt to write to a given file at the same time. > 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. > I would chalk the OP errors to computer "hiccups" , cause unknown. A > glitch in time & space. A blink of the Twilight Zone or is it Night > Gallery. The bits which go bump in the night. That is great deal less rational than my explanation! I fear we'll be discussing Ley Lines next :-( _______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
