<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Times New Roman">Hi Estani,<br>
<br>
I'm not advocating using the tracking_id to test whether two files
are identical. I'm suggesting that for most users, they will be
able to use it to determine whether they have the latest version
of a particular file, as opposed to some earlier version. It's
true that you can modify a file without changing the tracking_id,
but I'm pretty sure all but a tiny number of users will download
the files and never modify them. Whether or not a user alters
files, new files available from the CMIP5 archive will have
tracking_ids that the user doesn't have locally, so if they are
interested, they can download the new files.<br>
<br>
The above assumes that data *providers* take care to generate a
new tracking_id when they generate a file containing new data. Is
this a risky assumption? Couldn't the CMIP5 QA procedure check
whether a file has the same tracking_id as any other file in the
system?<br>
<br>
best regards,<br>
Karl<br>
<br>
</font>On 9/25/11 2:49 AM, Estanislao Gonzalez wrote:
<blockquote cite="mid:4E7EF93E.8000808@dkrz.de" type="cite">
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
I recall a problem that when altering the file with some tools
(cdo?) the tracking id wasn't automatically changed.<br>
Are we sure that the same tracking id point to the same file now?
<br>
Is the previous not a problem anymore?<br>
<br>
Thanks,<br>
Estani<br>
Am 24.09.2011 18:17, schrieb Karl Taylor:
<blockquote cite="mid:4E7E027D.50405@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
<font face="Times New Roman">Dear all,<br>
<br>
Concerning:<br>
</font><br>
On 9/24/11 4:35 AM, Estanislao Gonzalez wrote:
<blockquote cite="mid:4E7DC078.5000700@dkrz.de" type="cite">
<pre wrap="">2) checksums
They are the only reference to the outside that a data node give of the
changes a file suffered from one version to another, i.e. for
replication we use that information to retrieve only files that change
from one version to another. The same principle could be applied for
tools designed for end users.
</pre>
</blockquote>
<br>
without disputing that checksums should be mandatory, I want to
point out that a user who has lost the checksum associated with
a file he has downloaded shouldn't have to recompute the
checksum to determine whether his file is a copy of a file
residing at the datanode. Recall that recorded in each netCDF
file is a unique tracking_id, which I'm almost positive is also
in the thredds catalog. It will certainly be quicker for the
user to read the tracking_id and then check whether it matches
the latest version. I think we want to maintain tracking_id as
an option for checking whether new files exist in a new version.<br>
<br>
best regards,<br>
Karl<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
</blockquote>
</body>
</html>