Hi Julian,
I am looking at patching the issue on a 4.3.3 codebase (if that’s OK). I suppose the first thing is I have never contributed to an Open Source Project before and am not familiar with your protocols…. Would you mind Julian sending me on some information, if available on doing this.
Secondly, what I propose is that that all files installed by IZPack should use the Install Date, rather than the source modified date. There are two benefits of this update:
1) IZpack does not get involved with FileSystem settings – this is left to the machine the application is installer to
2) A previously installed source controlled application can be successfully updated and checked in.
To meet this requirement what I propose to deliver are the following updates:
Unpacker.java/MultiVolumeUnpacker.java:
As files are being unpacked, the following check is done to determine if an update is required:
If(pf.override() == PackFile.OVERRIDE_UPDATE){
overwritefile = (pathFile.lastModified() < pf.lastModified()
}
I propose that the time the installer is being executed is used.
If(pf.override() == PackFile.OVERRIDE_UPDATE){
overwritefile = (pathFile.lastModified() < System.currentTimeMillis());
}
In addition to the above check I am also proposing that the IZPack source does not set the date modified field.
The following snippet of code is removed:
// Set file modification time if specified
if (pf.lastModified() >= 0)
{
pathFile.setLastModified(pf.lastModified());
}
This means the PackFile class has a redundant property set (see below):
this.mtime = src.lastModified();
My proposed patch would remove all references of this unused property from PackFile.java.
So far, my internal testing of this update has been successful, to verify the update what I have done is:
Test A:
1) Run main application installer. Do not update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test B:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test C:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
4) Run the patch installer.
5) As the installer is running, the files being re-installed by are overwritten
Potential impact,
The only impact that I can see from making this change is as follows:
1) If I run an installer and the application timestamp is not modified.
2) Then for some reason I have to re-run the installer.
3) The previously the already installed files will be overwritten by the latest installation.
I have no problems issuing a patch for this update, as I am familiar with the IZPack source, however my scope of Installation is limited to internal requirements. My question is, are there any other impacts to this change?
Many thanks in advance,
Niambh
Bug
Open
Major
Hi Julian,
I am looking at patching the issue on a 4.3.3 codebase (if that’s OK). I suppose the first thing is I have never contributed to an Open Source Project before and am not familiar with your protocols…. Would you mind Julian sending me on some information, if available on doing this.
Secondly, what I propose is that that all files installed by IZPack should use the Install Date, rather than the source modified date. There are two benefits of this update:
1) IZpack does not get involved with FileSystem settings – this is left to the machine the application is installer to
2) A previously installed source controlled application can be successfully updated and checked in.
To meet this requirement what I propose to deliver are the following updates:
Unpacker.java/MultiVolumeUnpacker.java:
As files are being unpacked, the following check is done to determine if an update is required:
If(pf.override() == PackFile.OVERRIDE_UPDATE){ overwritefile = (pathFile.lastModified() < pf.lastModified() }
I propose that the time the installer is being executed is used.
If(pf.override() == PackFile.OVERRIDE_UPDATE){ overwritefile = (pathFile.lastModified() < System.currentTimeMillis()); }
In addition to the above check I am also proposing that the IZPack source does not set the date modified field.
The following snippet of code is removed:
// Set file modification time if specified
{ pathFile.setLastModified(pf.lastModified()); }if (pf.lastModified() >= 0)
This means the PackFile class has a redundant property set (see below):
this.mtime = src.lastModified();
My proposed patch would remove all references of this unused property from PackFile.java.
So far, my internal testing of this update has been successful, to verify the update what I have done is:
Test A:
1) Run main application installer. Do not update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test B:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test C:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
4) Run the patch installer.
5) As the installer is running, the files being re-installed by are overwritten
Potential impact,
The only impact that I can see from making this change is as follows:
1) If I run an installer and the application timestamp is not modified.
2) Then for some reason I have to re-run the installer.
3) The previously the already installed files will be overwritten by the latest installation.
I have no problems issuing a patch for this update, as I am familiar with the IZPack source, however my scope of Installation is limited to internal requirements. My question is, are there any other impacts to this change?
Many thanks in advance,
Niambh