|
I'll bet if you put a call to destStream.Flush() just after the Write while loop, it would solve the mystery.
I'm reasonably sure that the delay is due to the data actually being written to the file.
|
|
|
|
|
Flush is called by Close which is called by Dispose, which, of course, is called when leaving the using scope.
So no, calling Flush before the won't actually do anything different.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
It would solve the mystery by exposing exactly what's causing the slowdown.
|
|
|
|
|
Will it give information about network latency, data packets, etc.? No, it won't expose anything more than an extra statement to set a break point on.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
When you step over it, it will take a long time to execute the Flush statement.
It would solve the mystery for me, maybe someone else would be too dense.
|
|
|
|
|
Richard Andrew x64 wrote: maybe someone else would be too dense.
An uncalled for statement. If you can't remain civil then please don't comment.
There are other ways to debug a problem than just hitting F10. Knowing and understanding the processing that are occurring is also a big help.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Look who's talking about being civil!
You're the guy who's always breaking Rule 3 in HOW TO ANSWER A QUESTION.
|
|
|
|
|
I certainly didn't mean to start a fight over debugging... 
|
|
|
|
|
No fighting. Some people just resort to insults and deflection when their arguments can't be defended professionally.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Have you trying just using File.Copy to see if there is any difference? It does basically the same thing but it may be something to test. Otherwise I'd say it's just the process of finalizing the writing of a large file, nothing you're going to solve without stepping into the unmanaged realm.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Yes, my original statemet was
File.Copy(nd_CopyDrive.LocalDrive + "\\" + fi.Name, nd_CopyDrive.LocalDrive + "\\Archive\\" + fi.Name, b_overwrite);
This had the exact same delay.
|
|
|
|
|
Then again, I'd say there is nothing you're going to be able to do about it. Aside from performing the copy operation on the system where the files reside rather than going through a mapped drive.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Taking what you said
Aside from performing the copy operation on the system where the files reside rather than going through a mapped drive.
How can I do that?
|
|
|
|
|
Create a service on the machine which you can call or somehow trigger. Perhaps a WCF service, remember WCF isn't just for web, it is also used for interprocess communication
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
That's going to be difficult. There are ~600 devices this has to happen to.
|
|
|
|
|
svanwass wrote: devices
 I thought you were mapping a drive to a server?
Anyway, not much more to be said. Other than decreasing the size of the file, which I'm sure is not an option, there isn't anything more you can do that I'm aware of.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Yea, I have to map to 600 servers, archive some files (one of which is large) then copy over new version of those files.
|
|
|
|
|
Oh, and I did add all these statements after the while loop:
destStream.Flush();
destStream.Close();
destStream.Dispose();
Close is where it is hanging at. More thoughts?
|
|
|
|
|
As I said it's the process of finalizing and closing a large file. The data must be validated and header information written to the file and entries made in the FAT.
Of course, performance may also be affected by the performance of your network and any IO operations also being performed on the destination disk.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
try setting buffer length to less as possible but moderate enough.
I usually use 512KB or 1MB buffer length for large file handling.
Hope this will help you
|
|
|
|
|
How would the size of my buffer change the delay when calling the Close method? Wouldn't a smaller/larger buffer size effect the Flush method only?
|
|
|
|
|
Because the size of your file there's not much that can be done, but have you tried BeginWrite and EndWrite??? prolly asynchronous write can help...
I want to die like my grandfather- asleep, not like the passengers in his car, screaming!
|
|
|
|
|
No, I have not tried Begin/EndWrite. I read the MSDN article but to be sure, testing these out would satisfy Async writing?
|
|
|
|
|
I am trying stop a console and then wait for it to close and then start it again. But my while loop is not working correctly. Can someone help me with what I am doing wrong? Thanks
if (Properties.Settings.Default.daily1 == true)
{
IntPtr serverHandle = FindWindow(null, Properties.Settings.Default.locServer1);
stopserver(Properties.Settings.Default.locServer1, btnStart1, btnStop1);
while (serverHandle != null)
{
}
startserver(Properties.Settings.Default.locServer1, btnStart1, btnStop1);
}
|
|
|
|
|
dwayne2700 wrote: But my while loop is not working correctly.
Offhand, I can see that if serverHandle is initialized with a non-null value, you'll be stuck in an infinite loop.
If your call to FindWindow succeeds, then serverHandle will be non-null, and you'll be stuck.
You'll have to come up with some other way of determining when the server is stopped successfully.
modified on Sunday, April 18, 2010 7:56 PM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
