File Copy with FSO

I am doing a file copy using the FSO and have recently started seeing a
condition being met.

The copy job copies DB logfiles from one server to another but checks for
the LastModifiedDate and if it is the same as well as the size of the file
is the same, the script goes onto the next file.

If the sourcefile is newer than the target file, it copies the sourcefile to
the target location, overwriting the targetfile.

However, I am also catching if the targetfile is newer than the sourcefile
and this is where my problem is. I am finding a number of files where the
targetFile's LastModifiedDate is more recent by 1 second. The Month, Day and
Year are all the same, and not recent, but the time is 1 second newer.

If targetFile is being modified by my script, I would expect the modified
date to be more recent than it is -- the time of the copy.

This exact script is running on a number of log files copy processes but
this is the only one I am having this issue with.

Has anyone seen this issue happen when doing file copies?

Bart Perrier

Bart
Mon Oct 22 09:10:08 PDT 2007


"Pegasus (MVP)" <I.can@fly.com> wrote in message
news:uLX7dRMFIHA.4308@TK2MSFTNGP06.phx.gbl...
>
> "Bart Perrier" <bart_perrier@hotmail.com> wrote in message
> news:ue37EFMFIHA.1184@TK2MSFTNGP04.phx.gbl...
>>I am doing a file copy using the FSO and have recently started seeing a
>>condition being met.
>>
>> The copy job copies DB logfiles from one server to another but checks for
>> the LastModifiedDate and if it is the same as well as the size of the
>> file is the same, the script goes onto the next file.
>>
>> If the sourcefile is newer than the target file, it copies the sourcefile
>> to the target location, overwriting the targetfile.
>>
>> However, I am also catching if the targetfile is newer than the
>> sourcefile and this is where my problem is. I am finding a number of
>> files where the targetFile's LastModifiedDate is more recent by 1 second.
>> The Month, Day and Year are all the same, and not recent, but the time is
>> 1 second newer.
>>
>> If targetFile is being modified by my script, I would expect the modified
>> date to be more recent than it is -- the time of the copy.
>>
>> This exact script is running on a number of log files copy processes but
>> this is the only one I am having this issue with.
>>
>> Has anyone seen this issue happen when doing file copies?
>>
>> Bart Perrier
>>
>>
>
> The FAT file system has a 2-second granularity in file time
> whereas NTFS, Unix and other file systems use finer time stamps.
> I suspect one of your file systems uses FAT rather than NTFS.
>


Thanks for the timely response, Pegasus. Both servers are NTFS.

It has been working for quite some time and now every new file (two or three
per hour) meets this condition, everytime.

I am now noticing that each file meeting this DateDiff condition is about
10 - 12 days old. The new files created by this DB are getting copied.

Thanks again for the reply.

Bart

Pegasus
Mon Oct 22 08:58:18 PDT 2007


"Bart Perrier" <bart_perrier@hotmail.com> wrote in message
news:ue37EFMFIHA.1184@TK2MSFTNGP04.phx.gbl...
>I am doing a file copy using the FSO and have recently started seeing a
>condition being met.
>
> The copy job copies DB logfiles from one server to another but checks for
> the LastModifiedDate and if it is the same as well as the size of the file
> is the same, the script goes onto the next file.
>
> If the sourcefile is newer than the target file, it copies the sourcefile
> to the target location, overwriting the targetfile.
>
> However, I am also catching if the targetfile is newer than the sourcefile
> and this is where my problem is. I am finding a number of files where the
> targetFile's LastModifiedDate is more recent by 1 second. The Month, Day
> and Year are all the same, and not recent, but the time is 1 second newer.
>
> If targetFile is being modified by my script, I would expect the modified
> date to be more recent than it is -- the time of the copy.
>
> This exact script is running on a number of log files copy processes but
> this is the only one I am having this issue with.
>
> Has anyone seen this issue happen when doing file copies?
>
> Bart Perrier
>
>

The FAT file system has a 2-second granularity in file time
whereas NTFS, Unix and other file systems use finer time stamps.
I suspect one of your file systems uses FAT rather than NTFS.

Bart
Mon Oct 22 09:51:58 PDT 2007


"Bart Perrier" <bart_perrier@hotmail.com> wrote in message
news:OESNFYMFIHA.4772@TK2MSFTNGP02.phx.gbl...
>
> "Pegasus (MVP)" <I.can@fly.com> wrote in message
> news:uLX7dRMFIHA.4308@TK2MSFTNGP06.phx.gbl...
>>
>> "Bart Perrier" <bart_perrier@hotmail.com> wrote in message
>> news:ue37EFMFIHA.1184@TK2MSFTNGP04.phx.gbl...
>>>I am doing a file copy using the FSO and have recently started seeing a
>>>condition being met.
>>>
>>> The copy job copies DB logfiles from one server to another but checks
>>> for the LastModifiedDate and if it is the same as well as the size of
>>> the file is the same, the script goes onto the next file.
>>>
>>> If the sourcefile is newer than the target file, it copies the
>>> sourcefile to the target location, overwriting the targetfile.
>>>
>>> However, I am also catching if the targetfile is newer than the
>>> sourcefile and this is where my problem is. I am finding a number of
>>> files where the targetFile's LastModifiedDate is more recent by 1
>>> second. The Month, Day and Year are all the same, and not recent, but
>>> the time is 1 second newer.
>>>
>>> If targetFile is being modified by my script, I would expect the
>>> modified date to be more recent than it is -- the time of the copy.
>>>
>>> This exact script is running on a number of log files copy processes but
>>> this is the only one I am having this issue with.
>>>
>>> Has anyone seen this issue happen when doing file copies?
>>>
>>> Bart Perrier
>>>
>>>
>>
>> The FAT file system has a 2-second granularity in file time
>> whereas NTFS, Unix and other file systems use finer time stamps.
>> I suspect one of your file systems uses FAT rather than NTFS.
>>
>
>
> Thanks for the timely response, Pegasus. Both servers are NTFS.
>
> It has been working for quite some time and now every new file (two or
> three per hour) meets this condition, everytime.
>
> I am now noticing that each file meeting this DateDiff condition is about
> 10 - 12 days old. The new files created by this DB are getting copied.
>
> Thanks again for the reply.
>
> Bart
>

I have been talking with my DBA and it looks like the new files are being
created and copied just fine but the management of the Sybase DB is through
BAT files. We are also deleting logs older than 8 days from this server and
the BAT file is putting them back out there somehow.

Although I did find a logic error in my script, it is not causing this
issue.

Case Closed.
Bart Perrier.