[Tilesathome] Compress.pm and zip file names

Dirk-Lüder Kreie osm-list at deelkar.net
Mon Sep 1 16:24:46 BST 2008


Sebastian Spaeth schrieb:
> Dirk-Lüder Kreie wrote:
> 
>> All in all I'm quite pleased with the way the client is going, 
>> especially the code-cleanup. 
> 
> Happy to hear that
> 
>  > But I also see some issues wich had been
>> addressed already creep back (rename vs. move for example).
> 
> It turned out that neither rename nor move was to blame, both work in 
> general (with move being for platform agnostic). It was actually a 
> locking problem in addition to closing directories with "close" (and not 
> closedir) that had been opened with "opendir"

I actually remember reading that. So apologies for bringing that up.


>> Now to the point of this e-mail:
>> In Compress.pm we do take care to lock everything that could be 
>> problematic on multi-client setups, why then go through the hassle of 
>> zipping to temporary file names, which on some setups won't work 
>> because the zip program will add ".zip" to the filename there by itself?
>>
>> Is there some reason I missed why this is not done?
> 
> Yes there is a reason for that. In Compress.pm we lock the ".dir" 
> directory which contains all the .png files, so that is 
> multi-thread/multi-client safe. However, we zip the files directly to 
> the "/uploaded" dir and while they are being written. An uploading 
> client could already pick up the partial ".zip" file in "/uploaded" (it 
> is not locked!). That's why I name them ".zip.part" and move them to 
> .zip when finished.
 >
> Does this make sense to you? If you don't like that, the alternative 
> would be to create the .zip file in "WorkingDirectory" and move to 
> /uploaded when finished. I don't care which solution is used.

I vote for working directory, because there are implementations of "zip" 
around that will auto-add a ".zip" suffix.

>> The "old" client just had a number suffix (before the .zip suffix) in 
>> case there would be more than one zip with the same name, to avoid 
>> multiple tilesets in one zip or otherwise mangled zip files.
> 
> It's not to avoid multiple files with the same  name, it's to prevent 
> uploaders to pick up partially written zip files.
>  They only have the same name now if the same client (client_uuid) 
> produces the same layer tileset multiple tiimes in a row. And then 
> overwriting the old file is a welcome effect.

It will not be overwritten but the contents updated. Not sure this will 
always do what you want.

-- 

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080901/5e9d111b/attachment.pgp>


More information about the Tilesathome mailing list