Comment 8 for bug 687752
Revision history for this message
| Julian Edwards (julian-edwards) wrote Re: [Bug 687752] Re: It's impossible to check a librarian file's hash once it's expired | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On Tuesday 04 January 2011 13:29:31 you wrote:
> We should discuss all this in Dallas anyway.
That'd be great.
> I'm not clear on your original use case.
It's to prevent re-uploading/
archive context with different contents.
> Why do we have LFAs not linked to LFCs that we want
> to block from being reuploaded?
We never have that, I'm not sure why you think so. The only case is where the
LFC is deleted when the file is removed from disk (which we have to do or
there would not be enough librarian space).
> I suspect this is abusing the expiry
> system and you are better off with an explicit list of hashes that
> should not be reuploaded, rather than blocking a set of files that have
> expired for some reason or other.
We do a combination of both. It's perfectly acceptable to resurrect deleted
files as long as they have the same content.
I am pretty sure that the librarian was designed like this in the first place
with Soyuz in mind.
> Overloading the expired state of a
> file to block uploads seems dangerous as it becomes impossible to turn
> off this behavior if necessary.
We don't do that so it's moot.
Cheers.