On Wed, May 11, 2022 at 9:58 AM Soft Works <softwo...@hotmail.com> wrote: > > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Tobias Rapp > > Sent: Wednesday, May 11, 2022 9:46 AM > > To: ffmpeg-devel@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 _______________________________________________ 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".