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 iz
>     Sent: 03 May 2016 19:59
>     To: Nick Payne
>     Cc: get_iplayer at lists.infradead.org
>     Subject: Re: Spurious write permission error
>
>     > Sent: Monday, May 02, 2016 at 1:41 PM
>     > From: "Nick Payne" <nick.payne at internode.on.net>
>     > [snip]
>     > Unable to write to a directory lacking write
>     permission.INFO: Command
>     > exit code 255 (raw code = 65280)
>     > WARNING: Failed to tag MP4 file
>
>     That error message comes from AtomicParsley.

Well spotted  -  searching for ...
	Unable to write to a directory lacking write permission
... in the GiP PERL source draws a blank, but it's at 0x44D80 in
AtomicParsley.exe

AP has problems tagging large files, but I've just checked back to my
original post on that, and it generates a different error message, so I
don't know what to suggest further.

>	It is not
>     related to GiP itself or to accessing the download_history
>     file. That file is written before AtomicParsley runs. As you
>     implied with the use of "spurious", it isn't a problem with
>     access permissions - that is just assumed by AtomicParsley.
>     The message really just means that AtomicParsley failed to
>     rename the temporary (tagged) file back to the original file
>     name for some reason. I used to occasionally see this happen
>     on a USB disk attached to a router. I would also see ffmpeg
>     glitches with the same setup, so I just chalked it up to disk
>     contention and stopped using a network disk to host my output
>     directory. Of course, that may not apply to your case.

Perhaps a timing and/or write cache issue  -  if the new contents of the
file have not been entirely written to disk by the time the rename
instruction comes, then the file will still be locked.  If a write cache is
in use, flushing it may solve that, which usually occurs automatically on
file closure, so is GiP/AP closing the file properly?  Or perhaps putting a
sleep command in between file closure and renaming may remove the problem.

But note that file contentions CAN occur with multiple instances of GiP
running as I have suggested  - I know, because I've had them in the dim and
distant past!