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 beenaddressed 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
