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@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
