Also, once my patches to expose more of ISO9660 info get merged, we'd
also need the same info to be exposed for UDF volumes.
This patch adds ISO9660 probing to UDF volumes and here is the result I
see on my example UDF volume (together with my pending patch to expose
more ISO9660 information):
In order to kill libosinfo's infamous udev rule[1], we need to make blkid
report the following information as udev properties on IS09660 media so
that libosinfo can make use of that for detection:
1. Volume ID (already exposed as label).
2. System ID.
3. Publisher ID.
4. Application ID.
5. Boot record's boot system ID, (almost always 'EL TORITO
SPECIFICATION' if boot record is present).
[kzak@redhat.com: - add blkid_ltrim_whitespace() and use it together
with blkid_rtrim_whitespace() to trim white spaces
- enlarge blkid values to 128 bytes
- add generic blkid_probe_set_id_label() function
- always terminate all _ID with \0
- don't export the _IDs to blkid cache]
Karel Zak [Wed, 6 Feb 2013 16:26:46 +0000 (17:26 +0100)]
libblkid: make blkid_new_probe_from_filename() usable on whole-disk
This is stupid bug, when libblkid probe for partition table on
whole-disk device with old 0.90 Linux RAID then it creates clone of
the struct blkid_probe to avoid collisions with the original probing
setting.
If the cloned prober is unnecessary then it's deallocated by
blkid_free_probe() ... and this function also closes the file
descriptor if the device has been opened by blkid_new_probe_from_filename().
Fortunately we usually use open() + blkid_probe_set_device(), ...
except wipefs(1).
Reported-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Karel Zak <kzak@redhat.com>
libblkid: add Flash-Friendly File System (f2fs) support
This adds support for detecting Flash-Friendly File System (f2fs) to libblkid.
Based on work by Sven-Göran Bergh at http://www.mail-archive.com/busybox@busybox.net/msg17874.html
Signed-off-by: Alejandro Martinez Ruiz <alex@nowcomputing.com> Signed-off-by: Karel Zak <kzak@redhat.com>
Andy Lutomirski [Mon, 14 Jan 2013 15:58:57 +0000 (07:58 -0800)]
setpriv: run a program with different Linux privilege settings
This new command can set no_new_privs, uid, gid, groups, securebits,
inheritable caps, the cap bounding set, securebits, and selinux and
apparmor labels.
[kerolasa@iki.fi: a lot of small adjustment making the command to be good
fit to util-linux project]
Signed-off-by: Sami Kerola <kerolasa@iki.fi> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Karel Zak [Mon, 4 Feb 2013 10:28:09 +0000 (11:28 +0100)]
libblkid: add blkid_probe_step_back()
It seems that blkid_do_probe() is too high-level solution for some
mkfs programs (for example ext4 mkfs supports "undo" so all write
operations has to be implemented by filesystem specific functions).
The new function blkid_probe_step_back() resets internal libblkid
buffers and move probing stuff one step back. It means that the
previously used probing function will be called again in the next
blkid_do_probe() call. This allows to modify on-disk data and check
for backup superblocks or alternative magic strings. Something like:
while (blkid_do_probe(pr) == 0) {
... get SBMAGIC_OFFSET and SBMAGIC len ...
... use your private seek & write() ...
blkid_probe_step_back(pr);
}
References: https://bugzilla.redhat.com/show_bug.cgi?id=902512 Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak [Fri, 1 Feb 2013 14:59:58 +0000 (15:59 +0100)]
libblkid: remove optimization from verify( funrtion
Now libblkid (the cache based part) tries to probe for the cached
filesystem firstly. This optimization is broken, because:
* new another superblock could be on the device and the original
is already obsolete
* we still need to probe for partitions and raids
* the code was too fragile
The patch also suggests lsblk --fs in blkid.8 for end users. lsblk
read information from used db.
Reported-by: Andreas Hofmeister <andi@collax.com> Signed-off-by: Karel Zak <kzak@redhat.com>
Sami Kerola [Tue, 22 Jan 2013 23:27:00 +0000 (23:27 +0000)]
docs: usage function and gettext
I made following survey which was sent to all email addresses in po/
directory that had the on-going millenium as time when translator had
been active.
There are two quite common styles to write a command usage print out,
which one you prefer?
1. Each option as separated translatable string. 18 votes
2. Or the whole thing as one big output. 1 vote
3. No preference. 1 vote
The questionaire had also free text field asking 'Why do you prefer
that?', and here are the answers.
[Separately] It is easier to follow changes with the translations. If
you change only one line or two, the big string would change to fuzzy
and I have to check the whole thing to see what was changed in the
original. If the changed line is a single string, the string to check
is a lot shorter.
[No preference] Usually, if there is no reason to separate strings,
better keep them together so that the context is obvious. In the case at
hand, it might help if in some language e.g. one translated line is too
wide for the screen. This is unlikely, but... OTOH, with this solution,
if you change one string the whole translation will be discarded until a
translator comes and updates it...
[Separately] It may be a bit harder to get the formatting right, but it
is much easier in maintenance. With one option changing, the
translator immediately sees the spot. And even with a lazy translator,
program author will have all the options translated that have not
changed at all.
[Separately] First one would be more in elegant I believe
[Separately] I prefer to have them separately because they don't form a
single text paragraph. In other words, they can be translated
separately because they are complete and separate "sentences". Of
course consistency of format and word choices need to be taken care of,
but the fact that the messages appear next to each other in the PO file
should be enough. Also if the options are not translated separately,
adding or editing one option causes the translation of all options to
become fuzzy and if for some reason it isn't checked before next
release (happens sometimes), all of them will show untranslated to the
user.
[Separately] Translations are a lot easier to update that way. If an
option is added, removed or changed, only a small amount of text
becomes fuzzy. If everything is in one big output, a lot of text
becomes fuzzy, and you have to read a lot more text to discover what
exactly changed.
[Separately] When updating a fuzzy translation, with one big output
it's very tedious and error-prone to find out the reason for fuzziness,
i.e. what actually has changed in the msgid.
[Separately] Way easier to translate, and especially to spot
translation updates when one string gets removed, added or modified.
[Separately] Makes translation memory more efficient. Some hard terms
in the list don't prevent translation of the whole block. Actually the
beginning of the strings don't need any translation ta all before []
part. Information about the context can be provided in comments or the
context parameter.
[Separately] Please consider the case when a part of string, (= msgid)
is changed. It is marked as fuzzy in the .po files, we translators
have to check whole sentences for the difference between it and
previous version.
[Separately] Every sentence must be a separate translation unit.
[One big output] for performance to ouput strings
[Separately] In the second case, if only one option changes (or a new
one is added), the translator will see as if all of the options
changed, having to find out which one of them is really new or has
actually changed. Also, if the translator has had no time to update
the string, only one of the options will be shown in the original
language (which is arguably ugly, but better than nothing for many
users).
[Separately] It's easier to translate the options separately using
translation memory.
[Separately] Easier to separate and see changes
[Separately] more translator friendly
[Separately] From the user POV I found the separeted version more
interesting because if a maintainer can't update the translation fast
enough between releases the user will still get the current translated
string with the new ones untraslated. From the translator POV the big
output will give more context information as one can see the whole
command options. With a new string added while the rest is translated
having some context can be more difficult.
[Separately] Additions to the list or changes to one options means you
don't have to check all lines each time.
So unless you have very, _very_ good reason you should not output all
usage as one big table. This implies also that when large usage output
is changed it should be split to small hunks. That may be a bit more
work once, but the next change will pay the extrawork off so never
hesitate when splitting.
Reference: http://www.surveymonkey.com/s/QKZ75HK Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Sami Kerola [Sun, 20 Jan 2013 18:04:51 +0000 (18:04 +0000)]
docs: align nsenter.1 man page with howto-man-page.txt
Most visible change; the --target option has a path - explanation table
instead a long paragraph. This makes pairing of the information easier
for an average user such as me.
The rest of the changes are about aligning with howto, i.e., fix spaces
after dots, URL & mail address macros, remove inline emphasis where
possible, mark directory paths and words with underscore to be line
breakable, use optional option syntax from howto, cut line lenght to 80
chars.
Sami Kerola [Sun, 20 Jan 2013 18:04:53 +0000 (18:04 +0000)]
nsenter: adjust few error messages
The 'neither filename nor target' is changed to use errx() rather than
err(), because the errno is indicating success at the time of fatal error
which is wrong message for an user.
The "cannot open %s" is same string as in other files, making translators
to work less.
Remaining changes aim to ease understanding what went wrong for a
non-programmer audience.
projects / thirdparty / util-linux.git / log
