> A code change for which no use case exists and does not provide
> any benefit is not relevant. That's my point.

You've deleted me saying

>> You're talking as if MAX_PATH limited library loader is self-evidently
>> superior, and it is the loader that has no such limitation that has to 
>> justify
>> its existence. As far as I'm concerned it just the other way around.

and now claim that code change is irrelevant.

> Imagine, you are creating a software (no matter whether you're big or small,
> open or closed source, targeting business or home users, using a custom or 
> public built ffmpeg) and you bundle ffmpeg.exe with your software like many 
> are doing. Now, re-read my comments, maybe it will make more sense to you.

They do not. Customer ask for long path support and gets two responses:

1. Enable long path support via registry once, and never care about it again.
2. Convert path to absolute and prefix it with \\?\ every time you use our 
software.

I don't see how second workaround can be any good at all. With the first option,
customers can at least pressure Microsoft into making it a default, if registry 
tweak
is too much a hassle for them; with the second they're stuck with 
workarounds—forever.

> ffmpeg is already working pretty well in handling long file paths (also with 
> Unicode characters) when pre-fixing paths with \\?\

It handles them most of the time, but not always. I already mentioned that the 
code from
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295568.html
explicitly converts all backslashes into forward slashes for unknown reasons,
and that code will not work with \\?\ paths because //?/ is not a valid prefix.
There are probably other places like that. Examples you've given simply
do not exercise such code paths, but it does mean they do not exists.



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

Reply via email to