Spurious write permission error

[C E Macfarlane]

Please see below ...

www.macfh.co.uk/CEMH.html

>     -----Original Message-----
>     From: get_iplayer [mailto:get_iplayer-bounces at lists.infradead.org]On
>     Behalf Of Clive
>     Sent: 02 May 2016 17:16
>     To: get_iplayer at lists.infradead.org
>     Subject: Re: Spurious write permission error
>     
>     
>     Until recently I have routinely run 2/3/4 instances of gip from one 
>     Linux Terminal box with no problems - open multiple tabs in 
>     one session 
>     and run separate downloads in each, sometimes all radio or TV 
>     and other 
>     times a mix. I have not encountered a conflict with the 
>     download history 
>     getting corrupt. I have always refreshed the cache in one 
>     before running 
>     multiple. I know this does not help much but it does share an 
>     experience.

... and ...

>     -----Original Message-----
>     From: artisticforge . [mailto:artisticforge at gmail.com]
>     Sent: 02 May 2016 18:36
>     To: c.e.macfarlane at macfh.co.uk
>     Cc: Nick Payne; get_iplayer
>     Subject: Re: Spurious write permission error
>     
>     I am running GiP under MacOSX and Debian Linux .
>     
>     I run multiple different GiP fetches from the same directory nearly
>     everyday on both MacOSX and Linux.
>     My multiple I mean 3 to 4 different fetches going at once from the
>     same directory.
>     Never have an issue.

There is no doubt that if you run multiple instances, there must be at least a theoretical possibility that two or more instances will require access to a file at the same time, and I am certain that I have such contention troubles in the past.  As I have suggested, assuming that only one instance is downloading any one particular programme, the most likely culprits are the shared download history and caches.

However, there are various things that might alter how much of a problem this might be in practice, for example here are two:

1)	The OS  -  the OP was working with Windows, while all none of his respondents are.  It might be that Windows is less forgiving of attempts by one process to access a file that is currently being updated by another process.

2)	The speed of the hardware.  It is likely that filesystem timeouts are fairly accurately timed and constant across different hardware, while the time taken to actually update a file will be determined, or rather inversely determined, by the speed of the hardware.  Therefore, the faster the hardware, the less the likelihood of a contention causing a timeout.  I have fairly old hardware.

Regards