From: Soft Works <softworkz@hotmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi Date: Wed, 11 May 2022 07:57:59 +0000 Message-ID: <BN0P223MB0358DC5AC644A6E4373D3542BAC89@BN0P223MB0358.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <40ff7ed7-3583-104f-4c51-91eeb9847d38@noa-archive.com> > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@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) Kind regards, softworkz _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2022-05-11 7:58 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-24 12:08 nil-admirari 2022-04-24 22:04 ` Soft Works 2022-04-25 9:03 ` nil-admirari 2022-04-25 9:31 ` Soft Works 2022-04-25 9:51 ` nil-admirari 2022-04-25 11:12 ` Soft Works 2022-04-25 12:51 ` Hendrik Leppkes 2022-04-25 13:02 ` Martin Storsjö 2022-04-25 13:36 ` Soft Works 2022-04-29 19:08 ` nil-admirari 2022-04-25 13:17 ` Soft Works 2022-04-29 18:59 ` nil-admirari 2022-04-29 18:52 ` nil-admirari 2022-04-30 12:34 ` Soft Works 2022-05-05 20:20 ` nil-admirari 2022-05-05 22:38 ` Soft Works 2022-05-06 16:07 ` nil-admirari 2022-05-07 2:57 ` Soft Works 2022-05-07 17:33 ` nil-admirari 2022-05-07 17:59 ` Soft Works 2022-05-10 21:22 ` nil-admirari 2022-05-10 22:59 ` Soft Works 2022-05-10 23:32 ` Soft Works 2022-05-11 7:46 ` Tobias Rapp 2022-05-11 7:57 ` Soft Works [this message] 2022-05-11 8:08 ` Hendrik Leppkes 2022-05-11 9:03 ` nil-admirari 2022-05-11 13:32 ` Tobias Rapp 2022-05-11 20:50 ` Soft Works 2022-05-11 8:57 ` nil-admirari 2022-05-14 0:42 ` Soft Works 2022-05-15 19:53 ` nil-admirari 2022-05-15 20:34 ` Soft Works 2022-05-16 8:49 ` nil-admirari 2022-05-08 19:48 ` Martin Storsjö 2022-04-25 20:51 ` Stephen Hutchinson 2022-04-29 19:25 ` nil-admirari -- strict thread matches above, loose matches on Subject: below -- 2022-04-23 20:56 Nil Admirari 2022-04-24 3:39 ` Soft Works 2022-05-07 17:57 ` Soft Works
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BN0P223MB0358DC5AC644A6E4373D3542BAC89@BN0P223MB0358.NAMP223.PROD.OUTLOOK.COM \ --to=softworkz@hotmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git