I know this might be a stupid question.. but what filenaming convention are you using?<br><br>its not a random name based on Time or something where file names are accidentally reused?<br>im sure its not, but have to ask. <br>
<br><div class="gmail_quote">On Fri, Apr 13, 2012 at 12:14 AM, David Moorhouse <span dir="ltr"><<a href="mailto:delphi@moorhouse.net.nz">delphi@moorhouse.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Peter<br>
<br>
JC and I are working with JB on this project and it has us all stumped.<br>
<br>
Only one thread writes these files. �Standard threaded app, with one<br>
thread creating the files, and then signalling another thread when it<br>
has finished to consume the files.<br>
<br>
As JB says, the writer thread creates each file, then uses FileExists to<br>
check it is on disk. �This all works ok.<br>
<br>
However when the consuming thread does a FileFirst/FileNext scan some of<br>
the files do NOT exist on the disk.<br>
<br>
Single threading the app is not an option unfortunately :(<br>
<br>
We are nervous about the sleep - hence the call to the list. �Any other<br>
help appreciated.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
D<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 12/04/12 16:07, Peter Ingham wrote:<br>
> Just wondering of the key word in the problem description is ... "Thread".<br>
><br>
> Do you have multiple threads writing these files?<br>
><br>
> Are you sure your code is multi-thread safe?<br>
><br>
> Are you sure the VCL routines you are using are multi-thread safe (a<br>
> number are not)!!<br>
><br>
> If you force the app to have only one thread, does the problem go away?<br>
><br>
> If you force parts of the operation to run in the context of the main<br>
> thread (synchronize), does the problem go away?<br>
><br>
><br>
> Experience shows that short sleeps often change the conditions of a<br>
> threading bug. �I get especially nervous working with multi-threaded<br>
> code when I find sleeps that are there to "Fix" bugs.<br>
><br>
> Cheers<br>
><br>
> On 12/04/2012 2:59 p.m., Steve Peacocke wrote:<br>
>> Hi John,<br>
>><br>
>> All I can say is that I came across this before and resolved it in much<br>
>> the same way. I looked up the issue at the time and there was some<br>
>> convoluted explanation but in the end I just put it down to the<br>
>> programmer (me) being so fast that even a computer couldn't keep up. I<br>
>> could live with that explanation.<br>
>><br>
>> This was about 10 years ago.<br>
>><br>
>> Steve<br>
>><br>
>> On Thursday, 12 April 2012, John Bird wrote:<br>
>><br>
>> � � �I came across an oddity in a program that creates lots (eg 30,000+)<br>
>> � � �files exporting selected data from a database.<br>
>> � � �Some files disappear on slower PCs �even though they are created.<br>
>><br>
>> � � � �* Files are created in a thread using TFilestream, in a loop<br>
>> � � � �* Each file is being checked that it gets created using a if<br>
>> � � � � �FileExists(filename) in the loop and they always seem to be there.<br>
>> � � � �* Files are written at the rate of around 20-30 per second and are<br>
>> � � � � �mostly around 3KB in size.<br>
>> � � � �* At the end of the big loop a list of files created is created by<br>
>> � � � � �the usual FindNext code.<br>
>> � � � �* On some slower PC�s (XP or Server 2003) some files are missing.<br>
>> � � � � �Faster PC�s with Win7 have all the files. �All PC�s are VMs.<br>
>> � � � �* Files missing might range from 10 to 500, never the same number<br>
>> � � � �* The problem can be cured by putting a 2 millisecond sleep<br>
>> � � � � �between creating each file. �1 Millisecond is not enough.<br>
>><br>
>> � � �Can anyone shed any light on why this might be the underlying issue<br>
>> � � �and why a sleep might fix it?<br>
>> � � �John Bird<br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> Steve Peacocke<br>
>> Mobile: 0220 612-611<br>
>> Linkedin Professional Profile<br>
>> <<a href="http://nz.linkedin.com/pub/steve-peacocke/1/a06/489" target="_blank">http://nz.linkedin.com/pub/steve-peacocke/1/a06/489</a>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> NZ Borland Developers Group - Delphi mailing list<br>
>> Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
>> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
>> Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br>
><br>
><br>
> _______________________________________________<br>
> NZ Borland Developers Group - Delphi mailing list<br>
> Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
> Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br>
<br>
<br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Kyley Harris<br>Harris Software<br>+64-21-671-821<br>