[FFmpeg-devel] [PATCH] avutil/file_open: log temp filename

[Hendrik Leppkes]

On Wed, May 22, 2019 at 12:14 PM Gyan <ffmpeg at gyani.pro> wrote:
>
>
>
> On 22-05-2019 03:29 PM, Hendrik Leppkes wrote:
> > On Wed, May 22, 2019 at 11:51 AM Gyan <ffmpeg at gyani.pro> wrote:
> >>
> >>
> >> On 22-05-2019 02:29 PM, Hendrik Leppkes wrote:
> >>> On Wed, May 22, 2019 at 10:53 AM Gyan <ffmpeg at gyani.pro> wrote:
> >>>>
> >>>> On 22-05-2019 01:41 PM, Liu Steven wrote:
> >>>>>> 在 2019年5月22日，下午3:10，Gyan <ffmpeg at gyani.pro> 写道：
> >>>>>>
> >>>>>>
> >>>>>> Helps users to identify temp files for a given instance.
> >>>>>>
> >>>>>> In the longer term, we should aim to clean up all temp files.
> >>>>>>
> >>>>>> Gyan
> >>>>>> <0001-avutil-file_open-log-temp-filename.patch>_______________________________________________
> >>>>> Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE?
> >>>>>
> >>>> DEBUG and TRACE are meant to record micro-ops for debugging purposes.
> >>>> This message will be present a handful of times in the log and is
> >>>> essential for end-users so they can delete these files, which ffmpeg
> >>>> won't do, but should since these are meant to be temporary files.
> >>>>
> >>> Why don't we work on fixing this instead, as users will not know what
> >>> implications this message has in any case and just consider it spam.
> >> 1) A grep of the tree shows only two components make use of this
> >> function. The cache protocol, which needs to be expressly invoked by the
> >> user, and the xvid encoder in 2-pass mode, which also has to be
> >> expressly invoked. No unsuspecting user will be presented with this message.
> >>
> >> 2) Fixing this is the ideal solution. The above two components already
> >> unlink the file after use, but with cache:, the file remains available
> >> after ffmpeg has exited. So this has to be looked at by someone
> >> acquainted and able to test with all the environments that ffmpeg can be
> >> run on. I don't have that knowledge or access. Till then, let's not the
> >> perfect be the enemy of the good.
> >>
> > This message has absolutely zero indication that the user might need
> > to act on it, nevermind that API users might never see it in the first
> > place, as such I don't  see how this is even "good".
> >
> > Why don't you start with collecting information which systems are even
> > affected by this? You must have some systems where you saw this.
> This patch was prompted by a Windows user who wanted this info. As
> mentioned above, I can reproduce it with cache protocol on Windows.
> Don't have access to other systems, except one linux box.
>
> I just saw that we do have a file delete function. Will first see if
> that works.
>

I know that it doesn't work on Windows, because you have to
specifically request that a file can be marked for deletion while its
still open, which we do not do.

I'm working on a patch to see if we can fix this.

- Hendrik