This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Time Stamp changes Windows Server 2003
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 01, 2010
06:05 AM
Time Stamp changes Windows Server 2003
ISSUE:
When I create an Admin install point for my application on a Windows Server 2003 SP2 machine, the Timestamp of all non-versioned files change. The Date Created remains the same as in the package but the Date Modified changes to the current install time.
Certain points:
The installation can only be initiated through the custom bootstrapper that we have. This bootstrapper makes sure that we install the Admin point on a network share and not on a fixed drive.
We can map the network share as a drive on to our local machine or provide a UNC path during installation for creating the Admin point.
EXCEPTION:
There is no change in the TimeStamp if we do a normal install of the application on a Windows Server 2003 machine. That is, if we install the application with the INSTALLDIR as a fixed drive no Time Stamp change happens.
This behaviour is a Windows Server 2003 issue as it cannot be reproduced on any other OS.
MY FINDINGS TILL NOW:
This issue has something to do with the network path as local installation works fine.
I found this link during my analysis:
http://www.codeproject.com/KB/datetime/dstbugs.aspx
which speaks about Daylight Savings Time bug in NTFS.
QUERIES:
Is this a known issue?
If yes, why other OSs with NTFS do not behave the Windows Server 2003 way?
When I create an Admin install point for my application on a Windows Server 2003 SP2 machine, the Timestamp of all non-versioned files change. The Date Created remains the same as in the package but the Date Modified changes to the current install time.
Certain points:
The installation can only be initiated through the custom bootstrapper that we have. This bootstrapper makes sure that we install the Admin point on a network share and not on a fixed drive.
We can map the network share as a drive on to our local machine or provide a UNC path during installation for creating the Admin point.
EXCEPTION:
There is no change in the TimeStamp if we do a normal install of the application on a Windows Server 2003 machine. That is, if we install the application with the INSTALLDIR as a fixed drive no Time Stamp change happens.
This behaviour is a Windows Server 2003 issue as it cannot be reproduced on any other OS.
MY FINDINGS TILL NOW:
This issue has something to do with the network path as local installation works fine.
I found this link during my analysis:
http://www.codeproject.com/KB/datetime/dstbugs.aspx
which speaks about Daylight Savings Time bug in NTFS.
QUERIES:
Is this a known issue?
If yes, why other OSs with NTFS do not behave the Windows Server 2003 way?
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 20, 2011
01:45 PM
I'm working from a QA-side of this. You are correct in the behavior. In our case, I found this behavior isolated to the following conditions:
1. The shared folder exists on the physical server's local disk (that the network drive is mapped to).
2. The administrator has performed a (network or standalone) installation directly at the server.
3. The installation, regardless the installation type (standalone or network), was done to the mapped drive (i.e. the shared local folder).
This issue has plagued our application for years and finding information on tech threads have been fruitless. Thank you for the link you provided, because it's given me the first solid lead on this issue in a while.
Try installing the standalone version of your application to a network drive (following my above conditions) on a 2003 Server. I would like to know if you are yielding the same results.
I believe so, but is sorely under-reported. Interestingly, I found an MS article of a hotfix that's suppose to fix a similar issue: http://support.microsoft.com/kb/909423. This was included in the 2003 SP2 rollout. Oddly, I don't think the behavior occurred until after I did the SP2 update. I'll have to retest this clean 2003 machine again to confirm.
I'd like to know the answer to that myself. I'm not sure who to take this fight to... Microsoft, Installshield or both. Other installation packages I've tested don't exhibit this behavior under the same conditions BUT this is OS-specific, so it can go other way.
1. The shared folder exists on the physical server's local disk (that the network drive is mapped to).
2. The administrator has performed a (network or standalone) installation directly at the server.
3. The installation, regardless the installation type (standalone or network), was done to the mapped drive (i.e. the shared local folder).
This issue has plagued our application for years and finding information on tech threads have been fruitless. Thank you for the link you provided, because it's given me the first solid lead on this issue in a while.
Try installing the standalone version of your application to a network drive (following my above conditions) on a 2003 Server. I would like to know if you are yielding the same results.
QUERIES:
Is this a known issue?
I believe so, but is sorely under-reported. Interestingly, I found an MS article of a hotfix that's suppose to fix a similar issue: http://support.microsoft.com/kb/909423. This was included in the 2003 SP2 rollout. Oddly, I don't think the behavior occurred until after I did the SP2 update. I'll have to retest this clean 2003 machine again to confirm.
If yes, why other OSs with NTFS do not behave the Windows Server 2003 way?
I'd like to know the answer to that myself. I'm not sure who to take this fight to... Microsoft, Installshield or both. Other installation packages I've tested don't exhibit this behavior under the same conditions BUT this is OS-specific, so it can go other way.
