All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	sbrabec@suse.cz, kzak@redhat.com, util-linux@vger.kernel.org
Subject: Re: UDF label change since commit 2f2730bc77c9
Date: Tue, 16 Aug 2016 12:21:14 +0200	[thread overview]
Message-ID: <20160816102114.GF27284@quack2.suse.cz> (raw)
In-Reply-To: <20160815102642.GI30047@pali>

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

  reply	other threads:[~2016-08-16 10:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-01-28 18:46             ` Pali Rohár
2017-01-30 16:26               ` Jan Kara
2016-08-10 13:49   ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160816102114.GF27284@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=kzak@redhat.com \
    --cc=pali.rohar@gmail.com \
    --cc=sbrabec@suse.cz \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.