From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4CC5340EA2 for ; Wed, 11 May 2022 08:09:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C7EBF68B391; Wed, 11 May 2022 11:09:03 +0300 (EEST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7E73268B30C for ; Wed, 11 May 2022 11:08:57 +0300 (EEST) Received: by mail-lj1-f175.google.com with SMTP id l19so1555633ljb.7 for ; Wed, 11 May 2022 01:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zMZzZWS4o/gNoo0G0Agg7vi54bV9r0WmOeVRqJ3B45s=; b=LF3128MX2sC6wPzmtS3Y5Q5WHjXYYS6yn+V62fYTD7KfY/ClWmwABqSMrxJjXDHvJO f+wC/0em8Xs1ybeBimf0KbK7GcnMI4PGAeFUmxrguZKNEx/uOs73no4aAvBkvZ+r7wVb 1gNujE6iEtHfYcUEpwnYesM9fpcs4Db9NxMHryN0OMRcNpD5fKOxDAXo4guIHE7QaIgH 2HTYtFMeQroyOlDw/NWv7G10MZX3HvsyPxVC58a2PP7iFB3W0/3qiw/09k3lt9deW3c/ 9S/mSkDdaUuYy339erMj9oamD99aKWX2o+AuOCPYeKI+0FpFvNu7i6dXF6dv5nFdt2JZ kC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zMZzZWS4o/gNoo0G0Agg7vi54bV9r0WmOeVRqJ3B45s=; b=8NKBQp/zdZkkDlYDXcvkS4tmr64fla4XUg4iwdb8jPzM0rFrh9VWgf9M/eWN90d5SB 5+vvJDZmaMmSqqPjdYp+wGpNEUDYVE/BJ3Ym9Iab85a0VJTl4yfTxK/ZX/aXLOtOHp+e OoSaK71nV3+e3A4IDw9dr+CYKoRHRg19l6kAnEx1OqCvi7bLGOxaeRAG4g4d33ve7qhH QjyD2oBB5HR8RZDz7PfQJScS3OEccWLN1FKAw4Bl+Fn4Z4m0gl0iLbhE92Ajd+L8q0OG PRm0uB4FVVbz5mSJSyPPC2OyGRIb1DIB4KrFso0FCrdonkT0j8wkcjqgY4ir8UF/jYzM y4zg== X-Gm-Message-State: AOAM532c1SteSjmDSUOPIQLLiwppooCxC49aV8ayUz4q6O4Cvfnd1Exu yInworJfngUPDhC26K0oQuuDc3R1/eV04triq564WoC8 X-Google-Smtp-Source: ABdhPJxXAsXohHa3iB2Cae7N9smAR96XEFZfs2DiNT8epL8gzDhfL2OLQ0b5dsQbbUNCbdzgs7KKmu5IlW0kYrLOGcI= X-Received: by 2002:a05:651c:893:b0:249:4023:3818 with SMTP id d19-20020a05651c089300b0024940233818mr16912222ljq.44.1652256536221; Wed, 11 May 2022 01:08:56 -0700 (PDT) MIME-Version: 1.0 References: <40ff7ed7-3583-104f-4c51-91eeb9847d38@noa-archive.com> In-Reply-To: From: Hendrik Leppkes Date: Wed, 11 May 2022 10:08:43 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, May 11, 2022 at 9:58 AM Soft Works wrote: > > > > > -----Original Message----- > > From: ffmpeg-devel 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) > We've been over this - not every feature needs to be useful to everyone. The addition of the manifest does not make existing behavior worse, nor does it prevent working on an alternate solution in the future. These are not reasons to block it. If you want to contribute an alternate solution, you are welcome to do so, this does not block that or impede that in any way - if anything, it lays the groundwork to do that, because it already removes the MAX_PATH limitations from the code in various places. If you can provide an argument why this patch should not be applied that isn't "its not a 100% solution for everything", then you are welcome to do so, otherwise you are beating a dead horse at this point. If you want a better solution - provide one. - Hendrik _______________________________________________ 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".