On UUID's and MC file names

Bert Freudenberg bert at freudenbergs.de
Fri Jun 22 00:34:10 UTC 2007


we should take this discussion to squeak-dev. Reply-To set.

On Jun 22, 2007, at 1:06 , Jerome Peace wrote:

> Hi Bert,
> Thanks for the interesting response.
> ***
>> [V3dot10] Re: RV: Do in a workspace and say if could
> build
>> Bert Freudenberg bert at freudenbergs.de
>> Thu Jun 21 00:11:25 UTC 2007
>> On Jun 21, 2007, at 1:51 , Jerome Peace wrote:
>>> First a better way to print out a uuid. Since its
>>> based on time I should be able to take an encoded
>>> and print it out asHumanIntelligableText.
>> http://en.wikipedia.org/wiki/UUID
>>> Secondly it would seem that a time based version
>>> number would be a little less dangerous than a
>>> sequential version. So a package would be name
>>> somethink like:
>>> PackageName-subPackage-initials.yymmddnn.mcz
>>> with yymmddnn is a number based on time with a
>>> sufficient resolution to solve most problems.
>>> The details may be modified to meet other design
>>> criteria (e.g. spaceCompression).
>>> The first should be easy to do.
>> Reversing a cryptographic hash function? Have fun.
> Hmm. I don't have to reverse a hash function I just
> have to "know what it means".
> That can be done by extra info saved with the hash as
> part of the name.
> Enough info to provide a human intellegible clue.
> UUID hashes mean that on such and such a day at such
> and such a time from such and such a place a something
> was saved and given a uuid in such and such a format.
> If the purpose of the saving is not to keep secret
> what was saved you can place both the open text and
> the hash together and if needs be keep a dictionary to
> reverse the cyptographic hash.
> Partial progress counts. I just want to look as
> something that doesn't mystify me.
> Remember the context is to make something a beginner
> and an amatuer can learn.

That information is stored in the VersionInfo entry next to the UUID.  
It's easily accessible. Whereas the UUID might be generated using the  
UUIDPlugin and you have no idea how to reverse that. It's not  
sensible to even attempt that.

>>> I wonder what it would take to train MC to work
> with the second.
>> That's trivial. Since MC does not place meaning on
> the version name
>> you can just pre-populate the version name input
> field of the version
>> save dialog with whatever suits you.
> Huh? Wow.
> Does this mean I could rename the file and MC would
> still recognize it for what it is?
> Oh,. you said version name. So you mean that the
> packagename portion is still significant but I can
> play around with the version names and MC will pay no
> attention.

No. The package name is stored *inside* the MCZ.

> So a mischief maker could rename things so that
> Package-puck.30.mcz  was the ancestor of
> Package-puck.29.mcz instead of the expected other way
> around?
> On the other hand Package-puck.3.mcz duplicated and
> renamed to egakcaP-puck.3.mcz would not be recognized
> by MC as the same?
>> Actually, maybe having readable version file names is
> a problem in
>> itself. It gives the illusion that these have any
> meaning to MC.
>> Other systems like git avoid the problem by just
> using UUIDs as
>> filenames.
> And how would you know when mischief had happened
> then?

MC is not designed to prevent mischief, though the UUIDs prevent  
accidental mistakes. For actual security, one could for example use  
the hash of the entire package contents as identifier, making it  

- Bert -

More information about the Squeak-dev mailing list