Re: [PATCH] iso9660 UUID support by using the creation date/time

[Javier Martín]

El dom, 31-08-2008 a las 16:27 +0200, Felix Zielcke escribió:
> > > The specs say that it's allowed to contain only zeros but I think this
> > > shouldn't be a big problem.
> > 
> > I think this could indeed be a problem if it leads to collisions.  If "all
> > zeroes" is detected, one could rise an error in uuid() function to prevent 
> > the
> > caller from taking the value into consideration.
> 
> I have now used grub_error (GRUB_ERR_BAD_NUMBER)
> 
> But maybe it would be better to make a new type for this, though I don't
> have yet an idea how to call it.
> Suggestions please :)
What about:
 * BAD_FS looks the most contextual here, but if the ISO9660 standard
allows filesystems to "lack" the creation date, then they are certainly
not "bad", though for the purposes of the uuid function they are -
slightly confusing.
 * BAD_ARGUMENT as in "the FS you requested to id is not a valid
argument to this function", but this err code is usually applied for the
failure of argument precondition checks (non-empty device names, etc.)
 * INVALID_COMMAND as in "this command cannot be applied to that FS"
 * Or even NOT_IMPLEMENTED_YET as in "we still haven't figured how to id
this FS", but this seems to imply that we will eventually do.

By the way, reviewing BAD_ARGUMENT has reminded me that maybe the
function should check whether "uuid" is valid. If not, you don't need to
abort the operation, just the  malloc and consequent sprintf. If
implemented like this in all other FSs, this would be a fast way to
check whether or not a particular FS can have an UUID extracted without
actually having to get the id itself:

       /* ... */
         grub_error (GRUB_ERR_BAD_NUMBER, "No creation date in
filesystem to generate UUID.");
         if (uuid)
           *uuid = NULL;
       }
     else
       {
         if (uuid)
           {
             *uuid = /* ... */

-Habbit

signature.asc
Description: Esta parte del mensaje está firmada digitalmente