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.Private.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/mb2wpath.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.
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 think the activeCodePage=UTF-8 patch could break
Windows applications that expect the system-wide ANSI codepage to be
used for FFmpeg text output, though.
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
