Re: UDF label change since commit 2f2730bc77c9

[Jan Kara <jack@suse.cz>]

On Sat 28-01-17 19:46:57, Pali Rohár wrote:
> On Tuesday 16 August 2016 12:21:14 Jan Kara wrote:
> > On Mon 15-08-16 12:26:42, Pali Rohár wrote:
> > > On Monday 15 August 2016 11:43:37 Jan Kara wrote:
> > > > On Wed 10-08-16 16:23:06, Pali Rohár wrote:
> > > > > On Wednesday 10 August 2016 15:39:02 Jan Kara wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Wed 10-08-16 14:53:49, Pali Rohár wrote:
> > > > > > > On Wednesday 10 August 2016 14:38:59 Jan Kara wrote:
> > > > > > > > we have noticed that since commit 2f2730bc77c9 "libblkid:
> > > > > > > > udf: Fix reading LABEL, add support for UUID and other
> > > > > > > > udf identifiers" some volumes have changed labels which
> > > > > > > > are reported by blkid. See [1] for an example.
> > > > > > > 
> > > > > > > "You are not authorized to access bug #983165."
> > > > > > 
> > > > > > Ah, sorry. I forgot the bug is reported against SLES and so
> > > > > > is not publically visible. Anyway, the initial comment which
> > > > > > is interesting is:
> > > > > > 
> > > > > > I have a shared paritition with an UDF filesystem. In Win7
> > > > > > 64bit its label is 'ssd120_docs'. In SLES12SP1 its label is
> > > > > > 'ssd120_dokumente'. In Tumbleweed (and most likely also SP2
> > > > > > Beta) its label is 'ssd120_dosemut' (or similar garbage).
> > > > > > 
> > > > > > I think there should be some consistency in
> > > > > > /dev/disk/by-label/*. ---
> > > > > > 
> > > > > > As an explanation, SLES12SP1 uses util-linux 2.25 (i.e.,
> > > > > > before your patch), Tumbleweed is the rolling distro with
> > > > > > the latest & greatest version.
> > > > > > 
> > > > > > > > This is
> > > > > > > > because that commit changed what is used for the label -
> > > > > > > > previously we have used 'ident' in the Primary Volume
> > > > > > > > Descriptor, and after that commit we use Logical Volume
> > > > > > > > ID.
> > > > > > > 
> > > > > > > Yes, thats true.
> > > > > > > 
> > > > > > > > I think it would be better to keep consistency with older
> > > > > > > > util-linux releases (e.g. valid /etc/fstab that uses
> > > > > > > > labels may be broken by this change) but I'm not sure
> > > > > > > > whether there is a point once the new behavior has been
> > > > > > > > released in the util-linux release. But still I wanted
> > > > > > > > to raise this since I'm not sure how much util-linux
> > > > > > > > cares about these changes and also so that people are
> > > > > > > > aware of the change...
> > > > > > > > 
> > > > > > > > 								Honza
> > > > > > > > 
> > > > > > > > [1] https://bugzilla.suse.com/show_bug.cgi?id=983165
> > > > > > > 
> > > > > > > Reason why I proposed that change is because all other
> > > > > > > software use Logical Volume Identifier as label. Just
> > > > > > > linux blkid used something other.
> > > > > > > 
> > > > > > > Basically Linux was incompatible with whole world and I
> > > > > > > think this was a bug. Also UDF specification say something
> > > > > > > that LVI is displayed to user. IIRC also Grub2 uses LVI as
> > > > > > > label identification.
> > > > > > > 
> > > > > > > So I do not agree with reverting back old behaviour which
> > > > > > > is incompatible with everything except old util-linux
> > > > > > > versions...
> > > > > > 
> > > > > > Well, this somewhat does not match the description in the
> > > > > > bug. Apparently Win7 uses yet another identifier in the UDF
> > > > > > filesystem...
> > > > > 
> > > > > Not good :-( Anyway, are you able to produce/create UDF disk
> > > > > image/dump which show different label under Win7 and new
> > > > > util-linux? With that we can inspect which field is Win7 using
> > > > > and could test also other systems (like some BSD or Grub2)
> > > > > what see...
> > > > > 
> > > > > Maybe there could be different behaviour for CD, DVD, HDD or
> > > > > multisession CD/DVD...
> > > > 
> > > > The reporter has UDF filesystem created on HDD AFAIU. I've asked
> > > > him to run udf_test program on the fs image. From its output we
> > > > should be able to see various identifiers of the filesystem and
> > > > thus see whan Win7 uses.
> > > 
> > > Ok, that should help us to detect how Win7 get label...
> > > 
> > > Anyway, for such output is good tool udfdump from UDFClient project
> > > [1]. It has better license so it can be found in some linux
> > > distributions.
> > > 
> > > [1] - http://www.13thmonkey.org/udfclient/
> > 
> > Ah, good to know. Thanks! Sadly the reporter doesn't have the image
> > anymore. Just out of curiosity I've dumped information for Win 8.1
> > installation DVD I had lying around and there is one ID string in
> > Physical Volume Descriptor, one ID string in Physical Volume Set
> > Descriptor and then one ID string used for Logical Volume, Logical
> > Volume Set, and all other similar stuff. And this string looks the
> > most reasonable for a label. So I don't see much room for difference
> > between what Windows show and what current util-linux uses. Once
> > I'll reboot my machine to Win7, I'll check how it names the DVD.
> > 
> > 								Honza
> 
> Now I formatted USB disk with command:
> 
> $ mkudffs -b 512 --lvid=logical-volume-ident --vid=volume-ident --vsid=volume-set-ident --fsid=file-set-ident
> 
> And connected to Windows 10 machine. Windows identifies it as
> "logical-volume-ident" in "This PC".
> 
> So I think nothing was changed in Windows 10 and behaviour is same as
> in linux-util.

Good to know.

> Maybe there can be problem for optical discs where is bridged UDF with
> ISO filesystem and UDF part has different identifiers as those in ISO
> part?
> 
> And maybe... it is possible that some UDF filesystems on HDDs have also
> ISO identifiers and linux-util is confused what should use as label?

Maybe. As I already said the problematic image is not available any longer
so we can only guess. Probably this is not worth pursuing further unless
someone else starts complaining...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR