Subject: Re: Spurious write permission error
>
> > Sent: Monday, May 02, 2016 at 1:41 PM
> > From: "Nick Payne" <nick.pa...@internode.on.net>
> > [snip]
> > Unable to write to a directory lacking write
> permission.INFO: Command
>
t; -Original Message-
> From: Roger Bell_West [mailto:ro...@firedrake.org]
> Sent: 03 May 2016 16:04
> To: C E Macfarlane
> Subject: Re: Spurious write permission error
>
> On Tue, May 03, 2016 at 03:55:48PM +0100, C E Macfarlane wrote:
> >Tough
On Tue, May 03, 2016 at 03:55:48PM +0100, C E Macfarlane wrote:
> From: artisticforge . [mailto:artisticfo...@gmail.com]
> > 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
On Tue, May 03, 2016 at 08:48:47AM -0500, artisticforge . wrote:
> second, I do not do "Windows". That said, any operating system should
> prevent the deletion of a file that is in use.
Indeed. However, Unix-a-likes do let you delete directory entries for
files that are in use - the file is only
gt; -Original Message-
>> From: artisticforge . [mailto:artisticfo...@gmail.com]
>> Sent: 03 May 2016 12:27
>> To: c.e.macfarl...@macfh.co.uk
>> Cc: Nick Payne; get_iplayer
>> Subject: Re: Spurious write permission error
>>
>>
On Mon, May 02, 2016 at 10:40:01PM +0100, C E Macfarlane wrote:
> 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
>
Please see below ...
www.macfh.co.uk/CEMH.html
> -Original Message-
> From: artisticforge . [mailto:artisticfo...@gmail.com]
> Sent: 03 May 2016 12:27
> To: c.e.macfarl...@macfh.co.uk
> Cc: Nick Payne; get_iplayer
> Subject: Re: Spurious writ
hello
Race conditions as you suggest 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.
A design flaw that glaring would relegate the operating system to
hello
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.
The times I have had issues is
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
Please see below ...
www.macfh.co.uk/CEMH.html
> -Original Message-
> From: get_iplayer [mailto:get_iplayer-boun...@lists.infradead.org]On
> Behalf Of Nick Payne
> Sent: 02 May 2016 13:41
> To: get_iplayer@lists.infradead.org
> Subject: Spuriou
Running GiP 2.94 on Windows. I had two downloads running simultaneously,
both writing to the same directory. One download completed without any
problem indicated, the other put out the following on the console at the
end of the download:
INFO: MP4 tagging MP4 file
Started writing to temp
12 matches
Mail list logo
