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

[Soft Works]

> -----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)

Kind regards,
softworkz