[FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi

[Hendrik Leppkes]

On Wed, May 11, 2022 at 9:58 AM Soft Works <softworkz at hotmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Tobias Rapp
> > Sent: Wednesday, May 11, 2022 9:46 AM
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> > utf8toansi
> >
> > On 11/05/2022 01:32, Soft Works wrote:
> > >>
> > >> [...]
> > >>
> > >> The prefixing can be implemented as a function and then be used
> > >> in file_open.c.
> > >>
> > >> Other file system related functions like mkdir, rename, rmdir, etc.
> > >> are already intercepted in os_support.h, and the prefixing can be
> > >> applied there.
> > >>
> > >> Maybe I missed some cases, I have not fully analyzed the situation,
> > >> but surely there are just a small number of places that need to
> > >> be changed and not 587.
> > >>
> > >>
> > >> For the procedure of prefixing I would take a look at how it's done
> > >> in .NET. This is probably the most mature code for handling this
> > >> and might save us from dealing with issues and regressions until we
> > >> got it right.
> > >
> > > The logic they use is here:
> > >
> > >
> > https://github.com/dotnet/runtime/blob/main/src/libraries/System.Priva
> > te.CoreLib/src/System/IO/PathHelper.Windows.cs
> > >
> > > Probably it can be simplified a bit.
> >
> > Out of curiosity I searched for some automatic path prefixing code and
> > the author of this file claims that it should be handling most corner
> > cases:
> >
> > https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/src/m
> > b2wpath.c
> >
> > That amount of logic inside CorrectWidePath() does not look appealing
> > to
> > me. And even if we simplify that now I guess it will grow once the
> > corner cases drop in via bug reports.
>
> I would follow the MS code, that will be the safest way.
>
> > So I'm in favor of removing the MAX_PATH limit, converting needed
> > Win32
> > function calls from ANSI to WideChar, and adding the longPathAware
> > manifest flag.
>
> I'm not sure how much you had followed, so please excuse in case you
> had already read it: the manifest approach does not work on a default
> Windows installation.
> To activate long path support, the users needs to opt-in to a behavior
> that is probably deactivated by default for some reason. Also it
> requires administrative privileges to make this change.
> For me - and probably for others as well - that approach is useless,
> as it would be the same as if there would be no long path support.
> (when you cannot rely on that feature being always working, you
> cannot use it)
>

We've been over this - not every feature needs to be useful to
everyone. The addition of the manifest does not make existing behavior
worse, nor does it prevent working on an alternate solution in the
future.
These are not reasons to block it. If you want to contribute an
alternate solution, you are welcome to do so, this does not block that
or impede that in any way - if anything, it lays the groundwork to do
that, because it already removes the MAX_PATH limitations from the
code in various places.

If you can provide an argument why this patch should not be applied
that isn't "its not a 100% solution for everything", then you are
welcome to do so, otherwise you are beating a dead horse at this
point.
If you want a better solution - provide one.

- Hendrik