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

From: "Martin Storsjö" <martin@martin.st>
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: Mon, 25 Apr 2022 16:02:17 +0300 (EEST)
Message-ID: <4ce25d8b-efc0-2431-dc6-c2ad04d5f41@martin.st> (raw)
In-Reply-To: <CA+anqdzv7nqUz=eP99H5QED-dOqbm+LbbLzESHcCy8Ug_Feg5g@mail.gmail.com>

On Mon, 25 Apr 2022, Hendrik Leppkes wrote:

> On Mon, Apr 25, 2022 at 1:12 PM Soft Works <softworkz@hotmail.com> wrote:
>>
>> From my point of view:
>> ffmpeg is already working pretty well in handling long file paths (also with
>> Unicode characters) when pre-fixing paths with \\?\, and this is working
>> on all Windows versions without all the caveats, requirements and conditions
>> that I mentioned.
>
> "We have already worked around this problem in our deployment,
> therefore there is no need to try to improve it" is surely not a very
> strong argument.
>
> Will your work-around continue to work? Yes.
> Will the changes actually impact anyone negatively? No known case is
> documented, here or otherwise.
> Will this change objectively improve the operation of ffmpeg on
> Windows? Maybe not for everyone (yet), but certainly it'll allow it to
> do so in controlled environments.
>
> I'm not seeing a good argument here to generally block the patch on,
> as this entire thread boils down to .. what? Fear of change?
> Unless you can demonstrate an actual problem resulting from applying
> this patch, this line of arguments seems not very productive.

+1, I agree here.

Asking users to manually use \\?\ paths isn't something we should 
recommend as solution.

Internally prepending \\?\ when necessary could work (and would also be a 
possible fix, which at least would fix everything that goes through avio), 
but that's clearly much more risky than just adding a mostly-noop 
manifest. (And that only works for absolute paths; it requires some path 
munging logic to be able to do that.) I wouldn't mind going that way too, 
but the current patchset seems risk free to me.

FWIW, LLVM does something like that [1] - before opening files, it checks 
if a path seems to be too long, and if it is, it converts it into an 
absolute path and adds such a prefix. But that's clearly more risky and 
more nontrivial than this patchset.

[1] https://github.com/llvm/llvm-project/blob/llvmorg-14.0.0/llvm/lib/Support/Windows/Path.inc#L98-L124

// Martin
_______________________________________________
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".