Messages in this thread | | --nextPart2651272.T2METxLly0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Wednesday 14 June 2017 11:46:14 Jan Kara wrote: > Hi, >=20 > On Sun 11-06-17 17:10:02, Pali Roh=C3=A1r wrote: > > 2.1.3 Dstrings > >=20 > > The ECMA 167 standard, as well as this document, has normally > > defined byte positions relative to 0. In section 7.2.12 of ECMA > > 167, dstrings are defined in terms of being relative to 1. Since > > this offers an opportunity for confusion, the following shows what > > the definition would be if described relative to 0. > >=20 > > 7.2.12 Fixed-length character fields > >=20 > > A dstring of length n is a field of n bytes where d-characters > > (1/7.2) are recorded. The number of bytes used to record the > > characters shall be recorded as a Uint8 (1/7.1.1) in byte n-1, > > where n is the length of the field. The characters shall be > > recorded starting with the first byte of the field, and any > > remaining byte positions after the characters up until byte n-2 > > inclusive shall be set to #00. > >=20 > > If the number of d-characters to be encoded is zero, the length of > > the dstring shall be zero. > >=20 > > NOTE: The length of a dstring includes the compression code byte > > (2.1.1) except for the case of a zero length string. A zero length > > string shall be recorded by setting the entire dstring field to > > all zeros. =3D=3D=3D=3D=3D > >=20 > > Next in previous section 2.1.1 Character Sets is Compression > > Algorithm table where IDs 0-7 are reserved. > >=20 > > I'm not sure how to correctly interpret those sections. > >=20 > > Does it mean that every dstring should consist of following buffer? > >=20 > > L - length of encoded characters > > N - size of dstring buffer > >=20 > > buffer: > > 1 byte: 0x08 (for Latin1) or 0x10 (for UCS-2BE) > > =20 > > 2 - L+2 byte: encoded characters (data either in Latin1 or > > UCS-2BE) > >=20 > > L+2 - N-2 byte: 0x00 > >=20 > > N-1 byte: number L+1 > >=20 > > And in special case when L =3D 0, then first and last byte is also > > zero? >=20 > Yes, apparently that's what the spec says. >=20 > > Because currently we have different implementation in kernel udf > > driver, util-linux blkid library and in mkudffs from udftools. > > None of those implementation accept fully empty buffer as valid > > dstring. >=20 > As far as I'm looking, kernel handles this just fine. Note that > 'dstring' is actually rather rare in UDF. E.g. filenames are > recorded as d-characters which is something different. For > converting dstrings (only used for getting volume and set > identifiers) we use udf_dstrCS0toUTF8() which uses > udf_name_from_CS0() and that handles input length of 0 just fine. >=20 > > mkudffs stores at last byte length of encoded characters + 1 (for > > compression id) as written above. On the other hand blkid from > > util- linux things that last byte is part of encoded characters > > and Linux kernel driver does not set last byte to some value. >=20 > Linux kernel UDF driver never writes any dstring. >=20 > > So... how should be understood that UDF specification? Should last > > byte be set to length encoded characters + 1 or not? And should be > > fully empty buffer (also with compression id set to 0x00 which is > > reserved) treated as valid string (empty one)? > >=20 > > And... we should unify implementation of blkid, kernel udf driver > > and mkudffs. >=20 > I think you understood the spec correctly. What I think we should do > is to make udf-tools and blkid accept both variants but create the > one defined in the spec (to have higher chances for > interoperability). >=20 > Honza
mkudffs creates non-zero dstrings correctly since beginning. Zero=20 dstrings have set compression ID (first byte) and length to 1 (last=20 byte). This can be fixed, but I'm note sure if it is needed as=20 LogicalVolumeId (and others too) according to specification should not=20 be empty... But maybe it would make sense to allow user for some=20 specific situation to create such disk image (if user knows what is=20 doing).
Problem is in blkid parser which includes last byte into buffer for=20 decoding. As blkid stops at null byte, problem is only when byte before=20 length is non-null. E.g. when LogicalVolumeId (label) has exactly 30=20 Latin1 characters (LogicalVolumeId is 32 byte dstring).
I created patch for blkid with test case there:=20 https://github.com/karelzak/util-linux/pull/468
Similar patch would be needed also for grub2.
=2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com
--nextPart2651272.T2METxLly0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iEYEABECAAYFAllLhOIACgkQi/DJPQPkQ1LTxACdFjU6LMADFNZAq8vNKatpvFL2 kK0An0LLAqNnHADgsw6PJ9CVROXQ7jxT =SFi8 -----END PGP SIGNATURE-----
--nextPart2651272.T2METxLly0--
| |