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 7352D43216 for ; Wed, 25 May 2022 07:35:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7B46A68B4E0; Wed, 25 May 2022 10:35:00 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7F56068B4AA for ; Wed, 25 May 2022 10:34:54 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 24P7Yrt9018454-24P7YrtA018454; Wed, 25 May 2022 10:34:53 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 9E4B8A142D; Wed, 25 May 2022 10:34:53 +0300 (EEST) Date: Wed, 25 May 2022 10:34:53 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: ffmpegagent In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH v7 0/3] 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 Cc: Soft Works , Hendrik Leppkes , ffmpeg-devel@ffmpeg.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 24 May 2022, ffmpegagent wrote: > This patchset adds support for long file and directory paths on Windows. The > implementation follows the same logic that .NET is using internally, with > the only exception that it doesn't expand short path components in 8.3 > format. .NET does this as the same function is also used for other purposes, > but in our case, that's not required. Short (8.3) paths are working as well > with the extended path prefix, even when longer than 260. > > Successfully tested: > > * Regular paths wth drive letter > * Regular UNC paths > * Long paths wth drive letter > * Long paths wth drive letter and forward slashes > * Long UNC paths > * Prefixed paths wth drive letter > * Prefixed UNC paths > > I have kept the individual functions separate on purpose, to make it easy to > compare with the .NET impl. (compilers should inlinie those anyway) > > v2 > > * wchar_filename: Improve comments and function documentation > * os_support: adjust defines to use win32_stat > > v3 > > * removed length check in path_is_extended() > * added path_is_device_path() check in add_extended_prefix() > * add_extended_prefix(): clarified doc and add checks > * clarified string allocation length calculation > * replaced 260 with MAX_PATH > * removed redundant checks after normalization > > v4 > > * rebased. no changes > > v5 > > * resolved the ugly struct duplication > * compatible with _USE_32BIT_TIME_T > > v6 > > * wchar_filename.h: added links to .NET source code > * wchar_filename.h: free allocations on error > * os_support.hs: use clean and safe way to redirect stat() calls > > v7 > > * os_support.h: remapped fstat with win32_stat structure > * os_support.h: use int64_t for some members > * avformat/file: remove _WIN32 condition > > softworkz (3): > avutil/wchar_filename,file_open: Support long file names on Windows > avformat/os_support: Support long file names on Windows > avformat/file: remove _WIN32 condition Thanks, I think this iteration of the patchset is fine - I don't have anything else to add to it at the moment. Let's wait for others to chime in still before proceeding further with it, though. // Martin _______________________________________________ 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".