Home > Archive > Visual Basic > December 2005 > CopyFile truncates files
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
CopyFile truncates files
|
|
| phurst 2005-12-09, 6:56 pm |
| We have a Windows application that copies files from an XP workstation to a
Windows Server 2003 server. The app is written in VB6 and uses the CopyFile
method of the FileSystemObject. The code line is:
fso.CopyFile sourceFiles, destination
where sourceFiles is a string consisting of a path ending with "*.dat" so
multiple files may be copied. Each file consists of a set of fixed-length
data records but the number of records varies from file to file. The copy
process is initiated from a menu command.
The problem is that periodically a file is truncated on the server. After
about 600 files were transferred from 4 different workstations at 4 different
sites, we found 5 files had been truncated. 3 files from one site were
truncated after the 50th record in the file. The other 2 files were from
different sites and were truncated 3 characters into the first record. In
testing (transferred a few thousand files) we have not been able to truncate
a file without crashing the app, something that did not happen at any of the
sites.
Is CopyFile inherently unreliable?
Should we be doing something that we're missing?
A developer proposed adding a step to check each file on the server to make
sure that it has not been truncated, but we can't figure out how to test this
since we can't force a file truncation. Any suggestions would be appreciated.
| |
|
| Why don't you use FileCopy instead ?
>A developer proposed adding a step to check each file on the server to make
>sure that it has not been truncated, but we can't figure out how to test
>this
>since we can't force a file truncation.
At the end of the of the FileCopy, compare size.
"phurst" <phurst@discussions.microsoft.com> wrote in message
news:B00CB302-8DD0-4DEE-BC32-80EF27D3E3E5@microsoft.com...
> We have a Windows application that copies files from an XP workstation to
> a
> Windows Server 2003 server. The app is written in VB6 and uses the
> CopyFile
> method of the FileSystemObject. The code line is:
> fso.CopyFile sourceFiles, destination
> where sourceFiles is a string consisting of a path ending with "*.dat" so
> multiple files may be copied. Each file consists of a set of fixed-length
> data records but the number of records varies from file to file. The copy
> process is initiated from a menu command.
> The problem is that periodically a file is truncated on the server. After
> about 600 files were transferred from 4 different workstations at 4
> different
> sites, we found 5 files had been truncated. 3 files from one site were
> truncated after the 50th record in the file. The other 2 files were from
> different sites and were truncated 3 characters into the first record. In
> testing (transferred a few thousand files) we have not been able to
> truncate
> a file without crashing the app, something that did not happen at any of
> the
> sites.
> Is CopyFile inherently unreliable?
> Should we be doing something that we're missing?
> A developer proposed adding a step to check each file on the server to
> make
> sure that it has not been truncated, but we can't figure out how to test
> this
> since we can't force a file truncation. Any suggestions would be
> appreciated.
| |
| phurst 2005-12-09, 6:56 pm |
| It's not apparent to me how this is any different from our developer's
suggestion to check the file after it has been copied to the server. Perhaps
you could explain how changing to FileCopy improves on CopyFile.
"Ted" wrote:
> Why don't you use FileCopy instead ?
>
>
> At the end of the of the FileCopy, compare size.
>
>
>
> "phurst" <phurst@discussions.microsoft.com> wrote in message
> news:B00CB302-8DD0-4DEE-BC32-80EF27D3E3E5@microsoft.com...
>
>
>
| |
|
| You have to use FileSystemObject with CopyFile and distribute
the scripting dependency files which is not allowed to distribute,
plus you will be facing many problems if you do.
The FileCopy is simple and part of VB, you can trap errors
easily with it.
Example
On Error Resume Next
FileCopy "C:\Anything.exe, C:\Temp\Anything.exe"
if err.number > 0 then
err.clear
msgbox Err.Number & vbcrlf & Err.Description
end if
"phurst" <phurst@discussions.microsoft.com> wrote in message
news:1186B5F4-0BC1-4F53-BE55-317E47A442DA@microsoft.com...[color=darkred]
> It's not apparent to me how this is any different from our developer's
> suggestion to check the file after it has been copied to the server.
> Perhaps
> you could explain how changing to FileCopy improves on CopyFile.
>
> "Ted" wrote:
>
| |
|
|
"Ted" <2000@xxxmsn.com> wrote in message
news:%23zoeRBR$FHA.272@tk2msftngp13.phx.gbl...
> You have to use FileSystemObject with CopyFile and distribute
> the scripting dependency files which is not allowed to distribute,
Sure it is.
BUG: Distribution of Microsoft Scripting Runtime Library Fails
http://support.microsoft.com/kb/254166/EN-US/
Note that this KB article describes a bug in distributing the Scripting
runtime. The EXE it describes for installing the scripting runtime is freely
distributable with your apps.
Now, by NO means do I suggest or recommend using the FSO. I'm merely
pointing out that the scripting runtime can be redistributed.
> plus you will be facing many problems if you do.
No argument there. <g>
--
Mike
Microsoft MVP Visual Basic
| |
| J French 2005-12-10, 6:55 pm |
| On Fri, 9 Dec 2005 12:04:02 -0800, =?Utf-8?B?cGh1cnN0?=
<phurst@discussions.microsoft.com> wrote:
>We have a Windows application that copies files from an XP workstation to a
>Windows Server 2003 server. The app is written in VB6 and uses the CopyFile
>method of the FileSystemObject. The code line is:
> fso.CopyFile sourceFiles, destination
I totally agree with the others
- the FSO is a crock of sche*t
Much better do the same with pure VB or with the APIs
- copy to a Temp file, CRC it, then rename it
Personally I would use the most longwinded approach, to keep total
control. Logging and progress lines are a comfort blanket.
However I doubt that the files are really being truncated, it is
possible that there is some faulty error handling, or very faulty
logic going on.
If one is shunting files to something that picks them up and reads
them, then the safest thing is to send them to a temporary file and
rename it when the copy is complete.
On most file systems that I've played with a file being copied has a
length of zero until it is closed, but I would not count on that ...
If your developer is using the FSO then either sack him or send him
here for some remedial re-education.
| |
| mike williams 2005-12-10, 6:55 pm |
| "J French" <erewhon@nowhere.uk> wrote in message
news:439ae6dd.102709655@news.btopenworld.com...
> I totally agree with the others
> - the FSO is a crock of sche*t
Shouldn't that be sh*te Jerry? I can't make anything nasty out of sche*t -
but then maybe I've led a sheltered life ;-)
Mike
| |
| J French 2005-12-12, 7:56 am |
| On Sat, 10 Dec 2005 15:10:23 -0000, "mike williams"
<mike@whiskyAndCoke.com> wrote:
>"J French" <erewhon@nowhere.uk> wrote in message
>news:439ae6dd.102709655@news.btopenworld.com...
>
[color=darkred]
>Shouldn't that be sh*te Jerry? I can't make anything nasty out of sche*t -
>but then maybe I've led a sheltered life ;-)
German spelling, Mike
- but it means the same ...
| |
| Phill W. 2005-12-15, 6:55 pm |
|
"J French" <erewhon@nowhere.uk> wrote in message
news:439d5a38.263336757@news.btopenworld.com...
> On Sat, 10 Dec 2005 15:10:23 -0000, "mike williams"
> <mike@whiskyAndCoke.com> wrote:
>
>
>
> German spelling, Mike
> - but it means the same ...
Given the german predilection for concatenating-words-to-create-new-words,
what would /they/ have called the FileSystemObject?
DateiSystemGegenstand?
Another good reason not to use it ... ;-)
Regards,
Phill W.
|
|
|
|
|