From: "Pali Rohár" <pali.rohar@gmail.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: libblkid & empty identifier values
Date: Thu, 15 Jun 2017 09:57:22 +0200 [thread overview]
Message-ID: <20170615075722.GO5248@pali> (raw)
In-Reply-To: <20170615075244.xarzdd754ofbx3rp@ws.net.home>
On Thursday 15 June 2017 09:52:44 Karel Zak wrote:
> On Wed, Jun 14, 2017 at 11:04:34PM +0200, Pali Rohár wrote:
> > Hello!
> >
> > Technically UDF filesystem allows to store empty string values.
> > LogicalVolumeIdentifier (label) according to UDF specification shall not
> > be null, but it is possible to store empty string there.
> >
> > Question is, what should libblkid's udf code do if e.g. LABEL identifier
> > is empty string? Should it set empty LABEL for libblkid? Or it should
> > not set LABEL at all?
> >
> > Currently in blkid_probe_set_label() is check for len > 1, so empty
> > string is not possible to store for LABEL. But when check fails function
> > return non-negative value which is understood as succeeded -- even it
> > did not store empty string. It does not looks good... Or it is expected?
>
> IMHO think it's expected, blkid_probe_set_label() hides all the logic
> to keep probing functions simple. So, LABEL is optional and libblkid
> should not return any error if FS does not define any LABEL. The
> empty string as label is unwanted and unexpected by library clients.
Ok, in this case special logic for parsing empty UDF dstring identifiers
is not needed as they would be just ignored by libblkid (empty dstrings
are stored specially).
--
Pali Rohár
pali.rohar@gmail.com
prev parent reply other threads:[~2017-06-15 7:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 21:04 libblkid & empty identifier values Pali Rohár
2017-06-15 7:52 ` Karel Zak
2017-06-15 7:57 ` Pali Rohár [this message]
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=20170615075722.GO5248@pali \
--to=pali.rohar@gmail.com \
--cc=kzak@redhat.com \
--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.