On Tue, Jun 14, 2011 at 02:06:10PM +0200, Ludwig Nussel wrote:
> 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 :-)
OK. What about --force rather than --unsafe?
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
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
