UDF label change since commit 2f2730bc77c9

UDF label change since commit 2f2730bc77c9

[Jan Kara]

Hi,

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

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

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

Re: UDF label change since commit 2f2730bc77c9

[Pali Rohár]

On Wednesday 10 August 2016 14:38:59 Jan Kara wrote:
> Hi,

Hi!

> 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."

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

-- 
Pali Rohár
pali.rohar@gmail.com

Re: UDF label change since commit 2f2730bc77c9

[Jan Kara]

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

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

Re: UDF label change since commit 2f2730bc77c9

[Karel Zak]

On Wed, Aug 10, 2016 at 02:53:49PM +0200, Pali Rohár wrote:
> On Wednesday 10 August 2016 14:38:59 Jan Kara wrote:
> > Hi,
> 
> Hi!
> 
> > 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."
> 
> > 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...

I don't plan to revert it after 2 years and change it again. 

We had two possible solutions, but none is perfect. The selected
solution allows us to be more compatible with another systems, but
with a small regression that is very probably invisible for standard
CD users.  (This is first report after two years.)

See the original discussion about it:
http://marc.info/?l=util-linux-ng&m=141812346909875&w=2

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: UDF label change since commit 2f2730bc77c9

[Pali Rohár]

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

And I'm not sure if on WORM devices cannot be label changed by writing
new block somewhere to the end of disc (instead of rewriting original).

At least I can imagine that WORM devices could have different algorithm
for changing/reading UDF label due to write once.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: UDF label change since commit 2f2730bc77c9

[Jan Kara]

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.

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

Re: UDF label change since commit 2f2730bc77c9

[Pali Rohár]

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/

-- 
Pali Rohár
pali.rohar@gmail.com

Re: UDF label change since commit 2f2730bc77c9

[Jan Kara]

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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: UDF label change since commit 2f2730bc77c9

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 5628 bytes --]

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.

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?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: UDF label change since commit 2f2730bc77c9

[Jan Kara]

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