* UDF label change since commit 2f2730bc77c9 @ 2016-08-10 12:38 Jan Kara 2016-08-10 12:53 ` Pali Rohár 0 siblings, 1 reply; 10+ messages in thread From: Jan Kara @ 2016-08-10 12:38 UTC (permalink / raw) To: Pali Rohár; +Cc: sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-10 12:38 UDF label change since commit 2f2730bc77c9 Jan Kara @ 2016-08-10 12:53 ` Pali Rohár 2016-08-10 13:39 ` Jan Kara 2016-08-10 13:49 ` Karel Zak 0 siblings, 2 replies; 10+ messages in thread From: Pali Rohár @ 2016-08-10 12:53 UTC (permalink / raw) To: Jan Kara; +Cc: sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-10 12:53 ` Pali Rohár @ 2016-08-10 13:39 ` Jan Kara 2016-08-10 14:23 ` Pali Rohár 2016-08-10 13:49 ` Karel Zak 1 sibling, 1 reply; 10+ messages in thread From: Jan Kara @ 2016-08-10 13:39 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-10 13:39 ` Jan Kara @ 2016-08-10 14:23 ` Pali Rohár 2016-08-15 9:43 ` Jan Kara 0 siblings, 1 reply; 10+ messages in thread From: Pali Rohár @ 2016-08-10 14:23 UTC (permalink / raw) To: Jan Kara; +Cc: sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-10 14:23 ` Pali Rohár @ 2016-08-15 9:43 ` Jan Kara 2016-08-15 10:26 ` Pali Rohár 0 siblings, 1 reply; 10+ messages in thread From: Jan Kara @ 2016-08-15 9:43 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-15 9:43 ` Jan Kara @ 2016-08-15 10:26 ` Pali Rohár 2016-08-16 10:21 ` Jan Kara 0 siblings, 1 reply; 10+ messages in thread From: Pali Rohár @ 2016-08-15 10:26 UTC (permalink / raw) To: Jan Kara; +Cc: sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-15 10:26 ` Pali Rohár @ 2016-08-16 10:21 ` Jan Kara 2017-01-28 18:46 ` Pali Rohár 0 siblings, 1 reply; 10+ messages in thread From: Jan Kara @ 2016-08-16 10:21 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-16 10:21 ` Jan Kara @ 2017-01-28 18:46 ` Pali Rohár 2017-01-30 16:26 ` Jan Kara 0 siblings, 1 reply; 10+ messages in thread From: Pali Rohár @ 2017-01-28 18:46 UTC (permalink / raw) To: Jan Kara; +Cc: sbrabec, kzak, util-linux [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2017-01-28 18:46 ` Pali Rohár @ 2017-01-30 16:26 ` Jan Kara 0 siblings, 0 replies; 10+ messages in thread From: Jan Kara @ 2017-01-30 16:26 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, sbrabec, kzak, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UDF label change since commit 2f2730bc77c9 2016-08-10 12:53 ` Pali Rohár 2016-08-10 13:39 ` Jan Kara @ 2016-08-10 13:49 ` Karel Zak 1 sibling, 0 replies; 10+ messages in thread From: Karel Zak @ 2016-08-10 13:49 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, sbrabec, util-linux 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-01-30 16:26 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-10 12:38 UDF label change since commit 2f2730bc77c9 Jan Kara 2016-08-10 12:53 ` Pali Rohár 2016-08-10 13:39 ` Jan Kara 2016-08-10 14:23 ` Pali Rohár 2016-08-15 9:43 ` Jan Kara 2016-08-15 10:26 ` Pali Rohár 2016-08-16 10:21 ` Jan Kara 2017-01-28 18:46 ` Pali Rohár 2017-01-30 16:26 ` Jan Kara 2016-08-10 13:49 ` Karel Zak
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.