Issue 10832 - additional files with extension .zip lead to loop
Summary: additional files with extension .zip lead to loop
Status: CLOSED FIXED
Alias: None
Product: Installation
Classification: Application
Component: ui (show other issues)
Version: 644
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 1.1 Beta2
Assignee: stx123
QA Contact: issues@installation
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-21 17:01 UTC by stx123
Modified: 2003-09-08 16:53 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description stx123 2003-01-21 17:01:54 UTC 
The build of SRX644_n leads to additional .zip files 
in /instsetoo/wntmsci9.pro/01 and .../49
This produces a loop in setup.exe.
Comment 1 Martin Hollmichel 2003-01-21 18:29:55 UTC 
lzip (scpzip) creates .zip if file already exists.

for that reason output tree will be deleted before every new creation
of installation set. Obviously we had the case that instsetoo was
triggered for new build in buildserver, before last creation was finished.

either we need a lock mechanism for avoiding "double" builds of a
module or we should enable lzip to do incremental builds.

mh->rt: what would be your preferred solution ?
Comment 2 rt 2003-01-22 14:56:01 UTC 
lzip doing incremental builds sounds quite smart, but here I would
clearly prefer a locking mechnism. You don't know what else changed in
the build, therefor to be safe it is preferable to delete the first
install set and do a new one from scratch.

Rüdiger
Comment 3 Martin Hollmichel 2003-01-22 15:16:20 UTC 
since you're more familiar with locking implementaion, I reassign this
issue to you ;).
Comment 4 rt 2003-01-22 16:15:18 UTC 
I doubt that I am "more familiar with locking implementaion" than you.
Anyway, I'll look into it.
Comment 5 rt 2003-02-07 13:35:00 UTC 
After some time of thinking about this issue I changed my mind. A
locking mechanism in instsetoo/util/makefile.mk can't be the solution
here. The real bug is lzip leaving those *.zip files (I would guess it
always creates *.zip files and afterwards renames them. If such
renamed file already exists, the rename fails and a .zip file remains.
So the solution would be to delete the existing file before.). It is
always preferable to fix a bug than to work around it.
Dirk, is lzip on your list or is ir Gregors?

Rüdiger
Comment 6 dirk.voelzke 2003-02-17 10:09:36 UTC 
A better solution: Check if destination dir is empty.
Comment 7 gregor.hartmann 2003-02-17 11:38:00 UTC 
Checking for the Directory to be empty and exiting with an error would be better Because it could be 
possible that the current build generates less files than the previous (the one which created the files 
remaining in the directory)
Therefore it seems sensible to only pack in an empty directory and fail otherwise.

However when dmake is working twice at the same time this is a common problem and should be addressed is 
the proper tool which in this case cannot be the buildserver since it sets the define BSCLIENT which 
prevents instsetoo and instset from generating installation sets when triggered via buildserver.
This bug has to be fixed in build/dmake
Comment 8 gregor.hartmann 2003-02-17 13:52:38 UTC 
Will implement checking for empy directory before work starts.
Comment 9 gregor.hartmann 2003-02-17 14:40:08 UTC 
Created Issue #11560# for original bugdescription
Comment 10 gregor.hartmann 2003-02-17 14:54:08 UTC 
Is this task still P2 for OOo 1.1 Beta?
Comment 11 gregor.hartmann 2003-03-12 09:57:59 UTC 
Fixed in CWS gh3
Comment 12 gregor.hartmann 2003-03-18 12:25:57 UTC 
please verify
Comment 13 stx123 2003-03-24 11:55:31 UTC 
fixed
Comment 14 stx123 2003-03-24 11:55:49 UTC 
verified and closing