Karel Zak wrote:
> On Tue, Jun 14, 2011 at 01:45:34PM +0200, Karel Zak wrote:
> > On Wed, Jun 08, 2011 at 03:35:01PM +0200, Ludwig Nussel wrote:
> > > ---
> > > misc-utils/uuidgen.c | 4 +++-
> > > 1 files changed, 3 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/misc-utils/uuidgen.c b/misc-utils/uuidgen.c
> > > index 3cf6ec9..47f8e8f 100644
> > > --- a/misc-utils/uuidgen.c
> > > +++ b/misc-utils/uuidgen.c
> > > @@ -59,7 +59,9 @@ main (int argc, char *argv[])
> > >
> > > switch (do_type) {
> > > case DO_TYPE_TIME:
> > > - uuid_generate_time(uu);
> > > + if (uuid_generate_time_safe(uu)) {
> > > + fprintf(stderr, _("Warning: uuidd not running or not operational. Time based uuid may not be unique.\n"));
> >
> > IMHO this is overkill -- the uuidd is used very rarely (usually on
> > large systems with SAP) and it's disabled by default in many
> > distributions, but the uuidgen(1) util is available everywhere and
> > used probably often used by admins/scripts.
That's the problem exactly. uuidgen seems to work for them at first
until lots of uuids within a short time are required. It's a mean
trap.
> > It would be better to add some WARNING section to the uuidgen(1) man
> > page to inform users about the disadvantage.
Well, who reads docu if uuidgen -t appears to work?
> ... we can also add a new option (e.g. --safe) to use
> uuid_generate_time_safe().
... or make -t fail if it's not safe and add a --unsafe option. That
would be the fail-safe approach :-)
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
