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