Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

FileCopy() changes file time????

Posted on 1998-12-08
6
Medium Priority
?
312 Views
Last Modified: 2010-05-03
I run a VB5(SP3) application that reports differences between files on two drives based on the date/time of the file (as reported by the FileDateTime() function).  The app allows the user to copy the newer file over to the other drive (implemented by using the FileCopy() command) in order to synchroinze the two sets of files.

This works fine under Windows 95.  However, under Windows NT(SP3), when VB5's FileCopy() command copies a file to the other location, it modifies the time of the target file by adding one second to the new file's time.  (Yes, it really does.  I didn't believe it myself until I tested it.)  

The source file remains unchanged.  

This only occurs under Windows NT, and only when the target file in the FileCopy() function is removable media (A: or zip drive).  This same scenario does not occur when synching two directories on the same hard drive. (I only have one hard drive, so I can't test whether this occurs between two different hard drives)

Has anybody ever heard of such a thing?  Any ideas what's going on?
0
Comment
Question by:u42093
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
6 Comments
 
LVL 4

Expert Comment

by:Noggy
ID: 1448853
Weird!! I've not come across this myself but I may try it at work tomorrow.

I presume that this only happens with the FileCopy() method in VB? I.e. it doesn't happen when you copy a file in Explorer.

You say it happens when copying the file to another drive. Do you actually mean drive ("I only have one hard drive") or directory?

If it is another drive, I presume that it's on a network - in which case, are you using an NT server, Novell etc.??

I doubt that I would be able to help you but these are probably questions that other people are liable to ask. It certainly does seem a strange one though.

Good luck.
0
 

Author Comment

by:u42093
ID: 1448854
Hi.  Here are the answers to the questions in the previous comment:

1. Yes, it only happens with the FileCopy() method in VB.  When I copy the file via Explorer, the date/time is properly carried to the target file.

2. I only have one hard drive, but I also have a diskette drive (A:) and a parallel port zip drive (D:), and a CD-ROM (E:).  Most of my file synchronization tasks are between the C: drive and the parallel port zip drive (D:), and it was between C: and D: that I first noticed these problems.  So the answer to the questions is, yes, I intended to say to another *drive*.

3. As stated in #2, it's not a network drive, it's the D: zip drive or the A: diskette drive that are the targets of the file copies.

4. I'm glad someone else thinks this is weird, too!!!  I'm baffled...

Thanks!!!!!
0
 
LVL 13

Expert Comment

by:Mirkwood
ID: 1448855
Let me guess. NTFS disk?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 13

Expert Comment

by:Mirkwood
ID: 1448856
Does this sound familiar

BUG: VBApp FileCopy Updates Destination File's Date & Time Stamp
Last reviewed: July 29, 1997
Article ID: Q113958  
The information in this article applies to:
Microsoft Visual Basic, Applications Edition, version 1.0
Microsoft Excel, version 5.0
Microsoft Project, version 4.0


SYMPTOMS
The FileCopy statement in Visual Basic, Applications Edition does not maintain the Date and Time stamp of the source file when the destination file is copied. Unlike the MS-DOS Copy command and the FileCopy statement in Visual Basic version 3.0, the time stamp of the destination file shows the actual time the copy occurs.



WORKAROUND
Because the time stamp placed on the file is based on the current time, setting the system time to the time stamp of the source file prior to copying the file establishes the same time stamp on the destination file. Below is a sample piece of code to copy a file that maintains the same time stamp:


Sub TestFileCopy()
   Dim datOriginalDateTime As Date
   Dim datSourceTimeStamp As Date

   Const cSourceFile = "C:\AUTOEXEC.BAT"
   Const cDestFile = "C:\AUTOEXEC.OLD"

   ' Obtain Date/Time Stamp of the Source file:
   datSourceTimeStamp = FileDateTime(cSourceFile)

   ' Store Current time in a temporary variable:
   datOriginalDateTime = Now()

   ' Set System time to that of the Source File:
   Date = datSourceTimeStamp
   Time = datSourceTimeStamp

   FileCopy cSourceFile, cDestFile

   ' Restore System time to correct time:
   Date = datOriginalDateTime
   Time = datOriginalDateTime
   MsgBox "Source Date = " & FileDateTime(cSourceFile) & Chr(13) & _
      Chr(10) & "Destination Date = " & FileDateTime(cDestFile)
End Sub

STATUS
Microsoft has confirmed this to be a bug in the products listed above. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.



MORE INFORMATION


Steps to Reproduce Problem

Start Excel, or from the File menu, choose New (ALT, F, N) if Excel is already running.

Insert a New module. From the Insert Menu, choose Macro Module (ALT, I, M, M). Module1 is created by default.

Insert the following code into Module1:

   Sub TestFileCopy()
      Const cSourceFile = "C:\autoexec.bat"
      Const cDestFile = "C:\autoexec.old"
      FileCopy cSourceFile, cDestFile
      MsgBox "Source Date = " & FileDateTime(cSourceFile) & Chr(13) & _
         Chr(10) & "Destination Date = " & FileDateTime(cDestFile)
   End Sub


Run the macro. From the Tools Menu, choose Macro (ALT, T, M). From the Macro dialog, select the macro TestFileCopy. Then click the Run button.

The time stamps for the Source and Destination files differ. You would expect them to be the same. Now try the workaround routine, you will see the Source and Destination files are the same.
 


--------------------------------------------------------------------------------
 


0
 
LVL 2

Accepted Solution

by:
kswinney earned 1200 total points
ID: 1448857
If you're not comfortable jacking around with the system time, the following code sets the date and time of a file after copying:


Option Explicit

Private Type FILETIME
    dwLowDate               As Long
    dwHighDate      As Long
End Type

Private Type SYSTEMTIME
    wYear                   As Integer
    wMonth                  As Integer
    wDayOfWeek      As Integer
    wDay                    As Integer
    wHour                   As Integer
    wMinute         As Integer
    wSecond         As Integer
    wMillisecs      As Integer
End Type

Private Const FILE_SHARE_READ = &H1
Private Const FILE_SHARE_WRITE = &H2
Private Const GENERIC_WRITE = &H40000000
Private Const OPEN_EXISTING = 3

Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Private Declare Function CreateFile Lib "kernel32" Alias "CreateFileA" (ByVal lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, ByVal lpSecurityAttributes As Long, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long) As Long
Private Declare Function LocalFileTimeToFileTime Lib "kernel32" (lpLocalFileTime As FILETIME, lpFileTime As FILETIME) As Long
Private Declare Function SetFileTime Lib "kernel32" (ByVal hFile As Long, ByVal MullP As Long, ByVal NullP2 As Long, lpLastWriteTime As FILETIME) As Long
Private Declare Function SystemTimeToFileTime Lib "kernel32" (lpSystemTime As SYSTEMTIME, lpFileTime As FILETIME) As Long

Sub SetFileDate(sFileName As String, sDate As String)
    Dim hFile As Long
    Dim lResult As Long
    Dim udtSysTime As SYSTEMTIME
    Dim udtFileTime As FILETIME
    Dim udtLocalTime As FILETIME

    With udtSysTime
        .wYear = Year(sDate)
        .wMonth = Month(sDate)
        .wDay = Day(sDate)
        .wDayOfWeek = WeekDay(sDate) - 1
        .wHour = Hour(sDate)
        .wMinute = Minute(sDate)
        .wSecond = Second(sDate)
    End With

    lResult = SystemTimeToFileTime(udtSysTime, udtLocalTime)
   
    lResult = LocalFileTimeToFileTime(udtLocalTime, udtFileTime)
   
    hFile = CreateFile(sFileName, GENERIC_WRITE, FILE_SHARE_READ Or FILE_SHARE_WRITE, ByVal 0&, OPEN_EXISTING, 0, 0)
   
    lResult = SetFileTime(hFile, ByVal 0&, ByVal 0&, udtFileTime)
   
    Call CloseHandle(hFile)
End Sub

I hope this helps.
0
 

Author Comment

by:u42093
ID: 1448858
Sounds familiar, sort of.  This is indeed under NTFS, but there are a few discrepancies/contradictions between the published bug and what's happening to my app.  But all-in-all it sounds like you've given me both a possible explanation (bug) and a workaround (direct manipulation of the time on the destination file).  

The discrepancies are 1) this is not VB5 Applications Edition, it's VB5(SP3) Professional Edition and 2) the time of the copy isn't appearing on the destination file, it's the time of the original source file plus one second.  (For example, if the source file's time was 12:02:15, the destination file ends up being 12:02:16 after the copy).  

What a strange bug!  Thanks for the assistance.


0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction While answering a recent question about filtering a custom class collection, I realized that this could be accomplished with very little code by using the ScriptControl (SC) library.  This article will introduce you to the SC library a…
If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
Suggested Courses

715 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question