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 <standard.disclaimer>
