RE: [WiX-users] RE: Tallow and big file sets

[Rob M. <ro...@us...>]

Deletion of a file from a Component is a Component Rule violation.  In =
one
scenario, the deleted file can be "orphaned" on the user's machine.  In =
the
other scenario, the deleted file may never added to the machine because =
the
Component is "already installed" thus the new file is not necessary.

Both create really bad situations on the user's machine that are =
extremely
painful to debug.  Please, do not dismiss the Component Rules.  They can
seriously hurt our users.

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of
s.z...@in...
Sent: Monday, February 07, 2005 5:07 AM
To: WiX...@li...
Subject: [WiX-users] RE: Tallow and big file sets

Hi,
the tool is for helping the Setup author maintain a setup with many =
files
and
directories.=20
If a file is deleted from the disk, then it has to be removed from the =
wxs
file
otherwise the setup can't be built. So the tool does it for you in order =
to
save you the work to do it.
The protocol it generates, states which files are deleted from which
component,
so that the author can afterwards decide wether he wants to change the =
guid
of
the affected component or not.=20
It is up to the author to decide when a component rule is broken or not, =
the
tool just saves the author from the work of manually checking the whole =
file
list every time, and in the case no change has happened, it inform the
author
that the file list has remained stable, otherwise it performs the =
changes it
can automatically do, and leaves the author with a reasonable to-do =
list.
BTW. Deletion of a file from a component does not necessarily mean that
component rules are broken, IMO.
Stefan

Zitat von Vagmi Mudumbai=20
> Hi Stefan,
>=20
> As far as the WIX toolset is concerned, it need no know if the file
> has been changed. It would automatically read the relevant information
> from the file, like the version, size and it even writes the
> MsiFileHash table with the hash value (roughly the checksum) of the
> file. This is very useful while patching. Also you said that you were
> deleting files and folders from the wxs file. That is clearly a
> violation of component rules. This way, the file in the component gets
> removed and can cause seriouis inconsistencies during repair and other
> maintanance operations.
>=20
> This is how it used to work for us. Developers usually indicated the
> resource that can be deleted. What we do here is to set the transitive
> bit on the components and have it as fine grained as required. If the
> developer wants a file or a resource to be removed, we simple author
> the appropriate condition and poof... goes the resource during
> upgrade. However, on the flip side, you would have to maintain the
> latest good known file in your package and will be an overhead durin
> patch even if the only thing that you are going to do with that file
> is to delete it.
>=20
>=20
> On Mon, 7 Feb 2005 11:44:20 +0100, Stefan Zschocke
> <s.z...@in...> wrote:
> > Hi,
> > My current extension work will do the following:
> > Take an existing wxs file and start from a given pair of =
Wix-Directory
> > or DirectoryRef on the one side and a filesystem folder on the other
> > side. The Directory/DirectoryRef is located by its Id (input =
parameter
> > to my routine) and the filesystem-directory is located by its path
> > (input parameter to my routine). My routine then recursively =
iterates
> > through the filesystem, thereby detecting new files and =
subdirectories
> > as well as deleted files and subdirectories. For the new directories =
it
> > adds new Directory-tags, this is straightforward.
> >=20
> > For the new files it adds new files and possibly new components.
> > Concerning the new components: There is a boolean switch: One file =
per
> > component. If oneFilePerComponent is true, it adds a new component =
for
> > the new file and sets the file as keypath for the component. =
Otherwise,
> > it checks wether there already is one component in this =
Directory-node
> > and uses it. Only if there is none, adds a new component.
> >=20
> > For the deleted directories it deletes the Directory-node.
> > For the deleted files it deletes the File-node and if it was the =
last
> > one in the Component-node, deletes the Component, too.
> >=20
> > For the directories and files which could be matched, it does =
nothing.
> > This means that the existing tags (Directory, Component, File) =
remain
> > unchanged including the Component-Guid which is kept.
> >=20
> > It won't do anything actively with respect to component-rules. But =
it
> > will add a detailed comment-block to the output file, in which it
> > protocols the following: All deleted files, directories and =
component.
> > Also if a whole directory tree is deleted, it will list the deleted
> > subdirectories, files and components  therein. New components, files =
and
> > directories. Changed Components: The change means added or deleted =
files
> > within the component.
> >=20
> > The Setup-author must then revise this protocol and decide himself
> > wether a component-rule is broken or not.
> > I think this can't be done on a general level, with the exception =
that a
> > key-file of a component has been deleted. Otherwise, just adding or
> > removing a file of a multi-file component doesn't necessarily mean =
that
> > component-rules are broken. One can add an additional switch to the
> > tool, to specify that the Guid of Component with a key file deleted =
must
> > automatically be replaced by a new one, but generally the author =
should
> > decide, based on the protocol. Hence the need of a detailed
> > synchronization protocol.
> >=20
> > The one thing which is lacking here, is the detection of file =
changes.
> > For this to acomplish, one needs more than the existing wxs and the =
file
> > system. One would need at least a checksum of the old files. It =
would
> > not necessarily suffice to have recorded the old file's datetime and
> > size. For example if java-docs are regenerated from unchanged java
> > sources, the file size remains the same, but the datetime doesn't. =
Only
> > a binary comparison of the file contents will give a reliable result =
-
> > or otherwise a checksum. But where would one store these infos =
needed to
> > reliably detect file changes (datetime, size, checksum)?
> >=20
> > One option would be to have them in additional attributes of the
> > File-tag in the wxs file. These attributes (or possibly one only, =
which
> > combines these values) would need to be added to the wix-schema,
> > otherwise the generated wxs wouldn't compile. So this would mean
> > changing the wix-schema and I guess there would be resistance in the
> > community.
> > Otherwise have them stored elsewhere, well can be done...
> >=20
> > First I will implement the other stuff without detection of the file
> > changes...
> >=20
> > Stefan
> >=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: wix...@li...
> > [mailto:wix...@li...] Im Auftrag von =
Jonathan
> > Payne
> > Gesendet: Montag, 7. Februar 2005 10:22
> > An: wix...@li...
> > Betreff: [WiX-users] Tallow and big file sets
> >=20
> >=20
> > For a few of the products I work on, we need to be able to install =
large
> >=20
> > sets of files to go with the program (lots of sample documents, =
etc).  I
> >=20
> > would also like to be able to support upgrades using patches so I =
want
> > to follow the component rules carefully.
> >=20
> > I have been following the discussion about extending Tallow to =
manage
> > large sets of files as I want to automate the installation of these
> > files.
> >=20
> > I would like to work out how I can extend Tallow to support the =
cases I
> > need.  To support large file sets, Tallow would need to cope with =
files
> > being modified, added, deleted and re-added (deleted and then put =
back
> > in the same place later on).  For each of these, it is also possible
> > that the file might be the key file for a component.  There seem to =
be a
> >=20
> > lot of tricky cases if all of these were to be supported.  Deleting =
a
> > file that is the key file of a component doesn't seem like a good =
idea
> > and re-adding a file that was deleted in a previous version might
> > require special care to make sure it ends up in the same component.
> >=20
> > I am wondering if a lot of these would be made easier by having one =
file
> >=20
> > per component.  That way I could just store a unique ID for each =
file we
> >=20
> > install and every file would be a key file.  I have tried to find =
out if
> >=20
> > one file per component would work by making a few test installers.
> >=20
> > To install 10,000 files in 1,000 folders using 1,000 components (10
> > files per component):
> > Install time 54.062 seconds
> > Uninstall time 234.531 seconds
> > MSI size: 634,304 bytes
> > CAB size: 249,585 bytes
> > Install time per file: 5 ms
> > Uninstall time per file: 23 ms
> > MSI size file: 63.430 bytes
> >=20
> > To install 10,000 files in 1,000 folders using 10,000 components (1 =
file
> >=20
> > per component):
> > Install time 71.625 seconds
> > Uninstall time 258.891 seconds
> > MSI size: 1,315,076 bytes
> > CAB size: 249,585 bytes
> > Install time per file: 7 ms
> > Uninstall time per file: 26 ms
> > MSI size file: 132.508 bytes
> >=20
> > For comparison using Explorer with 10,000 files in 1,000 folders: =
Copy
> > time: 45 seconds Delete time: 12 seconds
> >=20
> > Both the installers were very basic MSI files and run with no UI.  =
From
> > these figures, it seems that if I can put up with the MSI file being
> > 700kb bigger, I can get much simpler file management and patching.  =
It
> > might also be possible to reduce the file size by picking the file =
and
> > component IDs carefully (I used IDs like "component9999" when I =
could
> > have compressed them down a bit).
> >=20
> > So my question is would installing each file as a separate component =
be
> > a really bad idea and is there anything else I should consider when
> > managing large file sets with WiX / Windows Installer?
> >=20
> > Jonathan
> >=20
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW -- Interactive =
Reporting
> > Tool for open source databases. Create drag-&-drop reports. Save =
time
> > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, =
etc.
> > Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > WiX-users mailing list
> > WiX...@li...
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >=20
>=20
>=20
> --=20
> Vagmi



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users