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 C78B041115 for ; Sun, 15 May 2022 19:02:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3EAB768B4C4; Sun, 15 May 2022 22:02:43 +0300 (EEST) Received: from msg-4.mailo.com (ip-15.mailobj.net [213.182.54.15]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BBA1768B4B2 for ; Sun, 15 May 2022 22:02:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1652641356; bh=DrhKaBEnokw6CiYwriabfjkB7Y8WCXEtzu6obN1pg2M=; h=X-EA-Auth:From:To:Date:Subject:MIME-Version:X-Mailer:Message-ID: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QVhv1mMvmSKffYqxTWabgUmiuNgLheE5ZfQyA3NQMXey2pY5rqWPYJK+kB6HkzTEi N2nbvxeAa2cnKG0C3rWHm52GNsMRAbMEJXI81nFhRLY0CEsikuqc22UW1tzuIIh+GZ 02dvxbSkZ9DMRynT/Vx7docwWOp1q8iA3dutPotg= Received: by www-7.mailo.com with http webmail; Sun, 15 May 2022 21:02:36 +0200 (CEST) X-EA-Auth: nQ9XctCMMneM12p3FQLnfCjWJ77AvYDQXdQ3GZijdUzexmcGCoPZNNJrfSCR1d63FRSOdFB59CCCsJInWtE00uz/c2pbF2q0 From: nil-admirari@mailo.com To: ffmpeg-devel@ffmpeg.org Date: Sun, 15 May 2022 21:02:36 +0200 (CEST) X-Priority: 3 MIME-Version: 1.0 X-Mailer: COMS/EA21.01/r20220415 Message-ID: In-Reply-To: <26c579e4ee0065a81f46b18adeba1b97385d8257.1652435595.git.ffmpegagent@gmail.com> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avutil/wchar_filename, file_open: Support long file names on Windows 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: > diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h > ... > +static inline int path_is_extended(const wchar_t *path) > ... Why path handling functions ended up in wchar_filename.h? Isn't it better to move them to file_open or os_support? > + num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL); Turns out that GetFullPathNameW handles long path names without the manifest or a prefix \\?\. Other WinAPI functions, require either a prefix or a manifest, which is why I thought that path normalisation must be done by hand. > +static inline int path_normalize(wchar_t **ppath_w) > +{ > + int ret; > + > + // see .NET6: PathHelper.Normalize() > + if ((ret = get_full_path_name(ppath_w)) < 0) > + return ret; > + > + /* What .NET does at this point is to call PathHelper.TryExpandShortFileName() > + in case the path contains a '~' character. > + We don't need to do this as we don't need to normalize the file name > + for presentation, and the extended path prefix works with 8.3 path > + components as well */ > + return 0; > +} This function simply forwards the return code of get_full_path_name(). The only non-trivial part of it is a comment. > +static inline int path_is_extended(const wchar_t *path) > +{ > + // see .NET6: PathInternal.IsExtended() > + size_t len = wcslen(path); > + if (len >= 4 && path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?') && path[2] == L'?' && path[3] == L'\\') > + return 1; > + > + return 0; > +} > > +static inline int add_extended_prefix(wchar_t **ppath_w) > +{ > + const wchar_t *unc_prefix = L"\\\\?\\UNC\\"; > ... > + // see .NET6: PathInternal.EnsureExtendedPrefix() > + if (path_w[0] == L'\\' && path_w[1] == L'\\') { > ... > + wcscpy(temp_w, unc_prefix); > + wcscat(temp_w, path_w + 2); > > +static inline int get_extended_win32_path(const char *path, wchar_t **ppath_w) > +{ > ... > + if (path_is_extended(*ppath_w)) { > + ... > + return 0; > + } > ... > + if ((ret = add_extended_prefix(ppath_w)) < 0) Actual PathInternal.EnsureExtendedPrefix (https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/IO/PathInternal.Windows.cs) checks for if (IsPartiallyQualified(path.AsSpan()) || IsDevice(path.AsSpan())) return path; where IsDevice handles \\.\, which you do not handle. If I'm not mistaken, the code paths presented above will turn such paths into \\?\UNC\\.\, which is an error. > +static inline int add_extended_prefix(wchar_t **ppath_w) > +{ > + const wchar_t *unc_prefix = L"\\\\?\\UNC\\"; > ... > + temp_w = (wchar_t *)av_calloc(len + 6 + 1, sizeof(wchar_t)); Wouldn't it be better to use sizeof unc_prefix instead of magic numbers? _______________________________________________ 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".