[hdf-forum] provenance

[Quincey Koziol]

Hi Mark,

On Mar 24, 2009, at 7:05 PM, Mark V wrote:

> On Wed, Mar 25, 2009 at 9:23 AM, Quincey Koziol  
> <koziol at hdfgroup.org> wrote:
>> Hi Dimitris,
>>
>> On Mar 24, 2009, at 5:14 PM, Dimitris Servis wrote:
>>
>>> Hi Quincey
>>>
>>> sorry it was not clear. I meant the UUID. If I copy the HDF5  
>>> "internal"
>>> UUID from one file to another along with the accessible contents,  
>>> I do not
>>> need to manipulate the time stamp of the target file to be the  
>>> same with
>>> that of the source file, so that applications that depend on the  
>>> stamp will
>>> not tell the difference. I ask all applications to check the UUID.
>>
>>        Hmm, I don't think copying the UUID to the new file is a  
>> good idea -
>> the UUID for each file created by the HDF5 library should be  
>> unique.  The
>> new file should get its own UUID...
>>
>
> This seems to come down to the question:
> Does the UUID refer to:
> a)  the file at a point in time, irrespective of contents.
> b)  the file contents at a point in time.
> c)  the file contents irrespective of time.
> d)  whatever the user wants it to refer to as 'unique'.
>
> I may misunderstand the intended usage. However it would be useful to
> document which is the intended use case.

	Good points! :-)  Yes, we should refine what this can be used for  
before implementing it.  I was mostly thinking of case c) where the  
UUID just allows one HDF5 file to be differentiated from any other one  
(and the same idea for each object, if the application chooses to  
store a UUID for the object).  Of course, a user could just copy the  
file entirely and then modify it, but that would be outside of the  
"system", since it was [at least partially] done outside of the HDF5  
library's knowledge.

> I'd be interested in (d) since it opens the scope for domain specific
> use cases.  I think the first 3 can be accommodated in some way by OS
> level data?

	Hmm, I'm not certain if the first three could be handled easily when  
the file moves around.  Case d) seems like it would be fraught with  
uncertainly for applications that attempted to use the UUID, unless it  
was an attribute that an application stored on the file/object.

	Quincey

> Mark
>
>>                Quincey
>>
>>> thanks!
>>>
>>> -- dimitris
>>>
>>> 2009/3/24 Quincey Koziol <koziol at hdfgroup.org>
>>> Hi Dimitris,
>>>
>>>
>>> On Mar 24, 2009, at 3:41 PM, Dimitris Servis wrote:
>>>
>>> Hi Quincey
>>>
>>> if it would be possible to copy it, I would also be interested. My  
>>> use
>>> case is this: when deleting large objects from the file, I copy  
>>> all objects
>>> to a new file and delete the old one. But some applications may  
>>> depend on
>>> the time stamp of the file and therefore I would have to modify  
>>> the time
>>> stamp of the new file using OS functions. Any unique ID would  
>>> solve this.
>>>
>>>       Are you wanting to copy objects' access/modification/etc  
>>> times, or
>>> the UUID for the file?
>>>
>>>               Quincey
>>>
>>>
>>> thanks!
>>>
>>> -- dimitros
>>>
>>> 2009/3/24 Quincey Koziol <koziol at hdfgroup.org>
>>> Hi Matthew,
>>>
>>> On Mar 24, 2009, at 1:32 PM, Matthew Dougherty wrote:
>>>
>>> Is there a unique identifier internally within an HDF file when it  
>>> is
>>> created?
>>>
>>> Something that would distinguish it from another HDF file created  
>>> two
>>> seconds later, and cannot be disabled or modified.
>>> Do not want to use the operating system/file system creation date or
>>> parameters in fstat, prefer a HDF api.
>>>
>>>      That's a good idea...  Would a UUID fit what you are thinking?
>>>  (http://en.wikipedia.org/wiki/Uuid)
>>>
>>>              Quincey
>>>
>>> On Mar 24, 2009, at 5:11 AM, Quincey Koziol wrote:
>>>
>>>      BTW, tracking these time for an object can be disabled by  
>>> calling
>>> H5Pset_obj_track_times() with the 'track_times' parameter set to  
>>> FALSE.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2502 bytes
Desc: not available
URL: <http://mail.hdfgroup.org/pipermail/hdf-forum_hdfgroup.org/attachments/20090325/c6f91047/attachment.bin>