Re: Unable to read UDF fs on a DVD

[Pat LaVarre <p.lavarre@ieee.org>]

> So concluding, I see no reason why this disc is not correctly
> read by Linux UDF.

Thanks for explaining.

I remember separately I saw the famous Ben F guess that the unamerican
chars were at issue: maybe the truthful or slanderous rumours of UDF in
2004 tripping over unamerican chars as often as other software does have
substance.

I imagine to experiment we may need to bring both Windows and Linux
together: either alone might convert between bytes and chars in a
lossless consistent way that only happened not to be standard.

> > $ egrep -i '(info|warning|error):'
> http://web.tiscali.it/kronoz/ucf_test.log
> >         PVD  72  Warning: Volume Set Identifier: "040420_0906",
> >         PVD  72  Warning: Volume Set Identifier: "040420_0906",
> >         Error: Number of AVDPs less than 2: 1, AVDP at 256
> > $
> > 
> > Non-compliance! ... I'm guessing ... Not explain the ls failure, 
> ...
> This error is no problem at all, nor are the warnings.
> The 2nd AVDP is required by UDF but redundant. It is only required to
> cope with the situation that the 1st AVDP at 256 is not readable.
> 
> No UDF implementation should refuse to mount because of this.

Lost me, help?

"No problem at all"?!?

We're discussing NON COMPLIANCE ... are we not?

That is, we're discussing a plain failure to meet the requirement,
tolerated because, by design, less than all actual UDF implementations
actually require all the published requirements.

Indeed, we know some programmers prefer to write code to comply only
with the de jure theory of the merely public specifications ... rather
than writing code that consciously quietly tolerates and thereby
encourages continuing violations of those specifications.

How then can we flatly say no UDF implementation should refuse to mount
because of a missing redundant AVDP?

Why can't someone reasonably choose to make their UDF more trustworthy
and simultaneously less friendly by requiring the redundant AVDP to be
present and in agreement?

Why must everyone trust the failure model that says the missing AVDP
doesn't matter?

Indeed, someone could reasonably require the Philips UDF Verifier to
bless a disc before automounting that disc.  No?

> ...

All that said, then yes for this specific case of Linux UDF, I agree
with you, Linux by design interoperates well with Windows, both as
delivered from Microsoft and as commonly patched, so here the de facto
standard of:
 
UDF IUVD LVInfo1: "!roxioUDF!n>2173136!s>0!d>286!"

wins over the de jure theory of a requirement for two redundant AVDP.

> 	PVD  72  Warning: Volume Set Identifier: "040420_0906",
> -		 expected: CS0 representation of unique hex number in
> -			   first 8 character positions, UDF 2.2.2.5.

Again the de jure theory of conformant VSID loses to the de facto
interoperability of tolerating such abuse?

> > >  Il volume nell'unita` D e` CDROM
> > >  Numero di serie del volume: A381-DC88
> > >  Directory di D:\
> > > 10/04/2004  20.59       240.695.296 Bakuretsu Tenshi - 01.avi
> > > 16/04/2004  15.13       240.715.776 Bakuretsu Tenshi - 02.avi
> > > 13/04/2004  18.57       182.452.224 Full Metal Alchemist - 11.avi
> > > ...
> 
> The Windows dir listing as reported by Luca is exactly what is
> reported by
> the UDF verifier.

"Thanks for explaining."

> The timestamps look different, but that is because the UDF
> verifier reports in UCT by default. With the '-localtime' option, also
> the times would be identical.

"Thanks for explaining."

> cc: linux_udf@h..., linux_udf-owner@h...

I hope I did right by deleting the linux_udf-owner from the cc.

Pat LaVarre