> You normally don't load libraries from such longs paths. And? 80% of FFmpeg functionality is normally not used.
> But file IO is a fundamental feature where a common and predictable > behavior is crucial. You're talking as if the manifest change somehow broke or fundamentally altered file IO, which it clearly did not. > That's true, but the file IO in ffmpeg does not use MAX_PATH buffers, > so it's only about those few specific cases: I'm glad it doesn't use MAX_PATH everywhere. Takes only 6 pathes to fix, not a thousand. > Patch 2/6: Removing the fixed-size buffer is surely a good change, > but can't you just completely remove the charset > conversion and use the same file IO patterns that ffmpeg > is using everywhere else? If you were to look at the code, you would've seen that charset conversion was already there. AviSynth is not Unicode-aware, it expects ANSI strings. Inline charset conversion was replaced by a library call, which, again, was already there, only slightly extended. > Patch 4/6: Seems to be pointless because you cannot run ffmpeg.exe from > a long path anyway. Neither with cmd nor with powershell. > Even if you could, it would be a pretty exotic use case. This current limitation may disappear in a future version of Windows, the same way path limit disappeared. > And the servers? Servers have the same lifecycle as client versions do. > And all those which are still using older versions? For them manifest change is a no-op. > Yes it is. Especially when you don't know that it's needed or whether > it's needed or when it is needed. > Also it requires administrative permissions which not everybody has. > Further it's a serious change to OS behavior and you cannot expect that > all users are educated enough for being able to make this decision > and be confident that it won't have any unexpected side effects. What does all of that have to do with these patches? > That's what I tried to explain. "Any other patch" makes a change > after which you know that the change has been made. > > But adding those attributes will impose changes that will be effective > under certain conditions only and about which neither the user nor the > application "knows" whether they are effective or not. Before these patches FFmpeg cannot handle long paths. After these patches, it can. They are certainly not invisible. > No. There's are common file APIs where such change could be made. During the review of these patches it was found that parts FFmpeg use av_fopen_utf8, while others use plain fopen. There is no common file API. > PS: Your line breaks were all doubled. Please check before replying. Were normal in email client. I don't know how they got garbled. My previous messages didn't have such a problem. _______________________________________________ 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".
