IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On Thu, Nov 20, 2008 at 14:17, Karel Zak <kzak@redhat.com> wrote:
> I see the patch (volume_id_probe_filesystem()) and a few things come
> to mind:
>
> - shouldn't be the relevant parts (label, uuid, version, ...) of
> the "struct volume_id" zeroized when you found a signature and
> before you call the next probing function?
>
> - it seems as overkill to use two for()s and probe two times for all
> filesystems. What about to store the first result and re-use it?
>
> - .. or at least never use the second for() when the fist for() found
> nothing ;-)
The klibc implementation of getopt_long() behaves slightly different
from the glibc one - in particular, it treats the change of the option
string argument between invocations as start of parsing a different
command line, and resets its state. However, the udevadm code
expected getopt_long() invocations in subcommands to continue parsing
the rest of command line after initial options has been parsed at the
top level; with klibc this broke, causing all udevadm subcommands to
stop recognizing their options.
Instead of relying on the glibc behavior, reset the getopt_long()
state properly before invoking the subcommand handler: move argv to
point to the subcommand name, decrease argc appropriately, and set
optind = 0. This also fixes a minor bug visible with glibc - without
setting optind = 0 all getopt_long() calls in subcommand handlers were
behaving as if "+" was specified as the first character of the option
string (which disables option reordering), because that state was set
by the first getopt_long() call at the top level, and was not reset
when parsing subcommand options.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
We probe for all known filesystems to find conflicting signatures. If
we find multiple matching signatures and one of the detected filesystem
types claims that it can not co-exist with any other filesystem type,
we do not return a probing result.
We can not afford to mount a volume with the wrong filesystem code and
possibly corrupt it. Linux ssytems have the problem of dozens of possible
filesystem types, and volumes with left-over signatures from former
filesystem types. Invalid signature need to be removed from the volume
to make the filesystem detection successful.
We do not want to read that many bytes from probed floppies, skip volumes
smaller than a usual floppy disk.
