Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Replacing non-versioned files

1 view
Skip to first unread message

Dewayne Christensen

unread,
Feb 11, 2002, 1:24:38 PM2/11/02
to
I was just reading through the file-replacement rules, and the rule applied
when neither the source nor the target file has a version doesn't make sense
to me. Say the user has MYPROG.EXE already installed on their system. The
file doesn't have a version resource, and it's created and modified dates
are 1/1/1999. Now we need to distribute a newer version of MYPROG.EXE. It
still doesn't have a version resource, but it's created and modified dates
are 2/1/2001. According to the replacement rules in the SDK, the file will
NOT be replaced. Does this make sense to anyone?

Rich - Microsoft Windows Installer MVP

unread,
Feb 11, 2002, 2:12:15 PM2/11/02
to
[Please do not mail me a copy of your followup]

"Dewayne Christensen" <NOdeway...@kscable.com> spake the secret code
<udx2nlysBHA.2560@tkmsftngp04> thusly:

>file doesn't have a version resource, and it's created and modified dates
>are 1/1/1999. Now we need to distribute a newer version of MYPROG.EXE. It
>still doesn't have a version resource, but it's created and modified dates
>are 2/1/2001. According to the replacement rules in the SDK, the file will
>NOT be replaced. Does this make sense to anyone?

Are you sure you're reading the rules right? What I read is that it
won't replace the file with the one in the distribution if the Created
and Modified dates of the existing file are different.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book http://www.xmission.com/~legalize/book/
Don't Support Spammers! Boycott Fractal Painter 7!
http://www.xmission.com/~legalize/spammers.html

Dewayne Christensen

unread,
Feb 11, 2002, 3:08:50 PM2/11/02
to
So you're saying that if file _B_'s created date doesn't match file _B_'s
modified date--meaning the file has been modified by the user--that it isn't
replaced? That makes more sense. I was reading it as saying that if file
_A_'s dates didn't match file _B_'s dates, that it wasn't replaced.

Then the followup question becomes, if file _A_'s two dates match each
other, and file _B_'s two dates match each other, which will be on the
system at installation completion, the newer file, or the already installed
file? Seems obvious that it should be whichever one is newer, but the doc's
don't specifically say. Whoever wrote that part needs to lucidify it a bit.


"Rich - Microsoft Windows Installer MVP" <legaliz...@mail.xmission.com>
wrote in message news:a4952f$5jt$1...@news.xmission.com...

Rich - Microsoft Windows Installer MVP

unread,
Feb 11, 2002, 3:17:08 PM2/11/02
to
[Please do not mail me a copy of your followup]

"Dewayne Christensen" <NOdeway...@kscable.com> spake the secret code

<uhAr2fzsBHA.2376@tkmsftngp07> thusly:

>So you're saying that if file _B_'s created date doesn't match file _B_'s
>modified date--meaning the file has been modified by the user--that it isn't
>replaced? That makes more sense. I was reading it as saying that if file
>_A_'s dates didn't match file _B_'s dates, that it wasn't replaced.

Yes, that's how I read it.

>Then the followup question becomes, if file _A_'s two dates match each
>other, and file _B_'s two dates match each other, which will be on the
>system at installation completion, the newer file, or the already installed
>file? Seems obvious that it should be whichever one is newer, but the doc's
>don't specifically say. Whoever wrote that part needs to lucidify it a bit.

In this case, I think if the file is not considered modified by the
user, then the file in the source is copied to the target machine,
replacing the existing file.

I too feel that using a date compare would be more intuitive here,
but it doesn't seem to work that way according to the docs.

0 new messages