From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75452C43381 for ; Fri, 8 Mar 2019 16:50:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4432A2147A for ; Fri, 8 Mar 2019 16:50:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=digidescorp.com header.i=@digidescorp.com header.b="ovD1mnzH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726628AbfCHQuh (ORCPT ); Fri, 8 Mar 2019 11:50:37 -0500 Received: from mail-io1-f41.google.com ([209.85.166.41]:37048 "EHLO mail-io1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726484AbfCHQuh (ORCPT ); Fri, 8 Mar 2019 11:50:37 -0500 Received: by mail-io1-f41.google.com with SMTP id v10so17246539iop.4 for ; Fri, 08 Mar 2019 08:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digidescorp.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=WLd2aNOrwGx7f/19Ahh6tdLZCBpAeOdBaSpAsTNLXcw=; b=ovD1mnzH9mZQM8E2AfVOoWPz04AzEB0S5q5woYTxXCWb8pUMGRZKMnYHMNudUnb/JH +70czcEPim1sN987k8ToDV5pWbUDXh7g3+hStkmT2EGWHmBSmSERWQR6Op6SYpLBivif YcaZsjt6KdmvFFDzXgeIR2/LA4CVNEUyBZtAg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WLd2aNOrwGx7f/19Ahh6tdLZCBpAeOdBaSpAsTNLXcw=; b=bDDb05+++Ya4ASFI/KoIFRhUwfZ5AyxC4DEJewBpN/rdTAPDy6jP34f+jaxCIMZwF7 g7wMzqgWhO3hbbuTm6DpDk2YtkaTo9oerEb4Qy1iY+f0VuVmjBbeY8YnZpWCXP3zjyGU bFPinpGCum3rfNy8LO+Wu4XZZb/eHioEQMZZgIe7roP2JaYUt0Aofq0B4LN3EfpwRoRo Ubemha8dIovcdbTJUE7b6BOXHdh4NhTdtBKmYvu82i9df42qBBEMa7UmGyuNe2LxIb3+ V8LE+enLMvnMhcufiO769oVgtzlwhKrd0oMJt/DjCPnGmXRmFuEE8l3UI83WY4NLXBZ6 Ls8g== X-Gm-Message-State: APjAAAWRbnaF2RJHurO0o/GoyQhFGoWOo8+sgV28g3zgJTObJl5P17Xu cMl3pYfx9/7n8sTBu+PZhoVRxs2iyxA= X-Google-Smtp-Source: APXvYqyyMFBNRT1jKBdTbD6qsLZtPGrMITMl+6H89l+U1pzBLknfnWtYBub/A5gg3zgYOA7Z+8QcIg== X-Received: by 2002:a6b:ec17:: with SMTP id c23mr10958477ioh.298.1552063835764; Fri, 08 Mar 2019 08:50:35 -0800 (PST) Received: from [10.10.6.128] ([50.73.98.161]) by smtp.googlemail.com with ESMTPSA id 202sm4760534itl.1.2019.03.08.08.50.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 08:50:35 -0800 (PST) Subject: Re: [RFC] udftools: steps towards fsck To: =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: Jan Kara , reinoud@netbsd.org, Colin King , =?UTF-8?Q?Vojt=c4=9bch_Vladyka?= , linux-fsdevel@vger.kernel.org References: <17e5fea5-8d76-c96d-8902-9050acba4288@digidescorp.com> <20190307102349.q5not23mve2soope@pali> From: Steve Magnani Message-ID: <1ebc384c-3944-9b7a-5b0e-bef5f78d9fdb@digidescorp.com> Date: Fri, 8 Mar 2019 10:50:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190307102349.q5not23mve2soope@pali> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Hi Pali, On 3/7/19 4:23 AM, Pali Rohár wrote: > On Wednesday 06 March 2019 20:44:54 Steve Magnani wrote: >> ... >> > udftools project was moved to github: > https://github.com/pali/udftools/ > > Ben (original project developer) also updated sourceforce page and you > can see there a big blue box "This project can now be found here." which > points to github. >> ... >> > As project page was moved to github I converted also whole source code > history. You can find there also that that old chkudf code... > > https://github.com/pali/udftools/tree/87acf1a2306b7b60ed9d61b53c2a487ea5f3396c/src/chkudf Right. But AFAICS there is no way to get _from_ the link in the "big blue box" _to_ the chkudf path you cite via normal browser navigation. Also I see no evidence of chkudf when using qgit or git-cola to browse a clone of the udftools repo. This is why I was working from the original CVS repo. Since your git-fu is stronger than mine, can you educate me on how to navigate to this tree without a magic URL? Are there better tools that I should be using to work with local GIT repo clones? > But, I would like to let you know that Vojtěch (CCed) started working on > udffsck implementation as part of his master thesis and current WIP code > is available on github in pull request: > > https://github.com/pali/udftools/pull/7 > > So it would be great if you look at new code and probably help Vojtěch > to finish new effort as trying to port and fix 20 years old code which > was already removed from udftools project... Sure, I was hoping to pool resources. One suggestion - since udffsck is much-desired, and you have a pull request, a reference to it either in a README within the stub udffsck folder or a printf() to that effect added to main() would make it more obvious that work is in progress and where to find it. I checked the udftools Github repo when I started this adventure but it never crossed my mind to look through pull requests. >> Some questions for consideration: >> >> ... >> >> * For any standards-based parser it's important to have examples of as many >> variations as possible (both normal and pathological) in order to ensure >> that corner cases and less common features are tested properly. Can anyone >> point me to any good sources of UDF data for testing? There are always >> commercial DVDs and Blu-Ray discs, of course, and I've cobbled together a >> few special cases by hand (i.e., a filesystem with directory cycles), but I >> have no examples with extended attributes or stream data. If I could find a >> DVD of Mac software in a resale shop would that help? [Side note, I've >> thought of enhancing chkudf to support a tool that would store all the UDF >> structures of a filesystem in a tarball that could be used to reconstitute >> that filesystem within a sparse file. Since none of the file contents would >> be stored the tarballs would be relatively small even if they represent >> terabyte-scale filesystems. Any thoughts on this? It would seem like a library of test cases would help both udftools and kernel driver development. >> >> * Are there versions (or features) of UDF that are less important to support >> than others (1.50? Strategy 4096? Named streams? etc.) I know 1.02, 2.01, >> and 2.50 are in wide use. > Currently udftools support UDF revisions 1.01, 1.02, 1.50, 2.00, 2.01 > and for BD-R (without metadata partition) also 2.50 and 2.60. I'm not quite sure how to read this. Currently-functional tools such as mkudffs support those versions? Vojtěch's code supports those versions? All of the versions are equally represented in field use? The reason I was asking was to try to prioritize development, to avoid getting bogged down (at least initially) in details of UDF that don't have as much practical significance. Regards, ------------------------------------------------------------------------  Steven J. Magnani               "I claim this network for MARS!  www.digidescorp.com              Earthling, return my space modulator!"  #include