RE: create()
brian at aljex.com
brian at aljex.com
Tue Sep 3 11:23:12 PDT 2013
Unlikely.
Even on Windows.
If that were really true, then Windows wouldn't just be less reliable or more virus prone, the system wouldn't even run for one minute. It would not even be able to get booted up if such basic functions were not trustworthy.
You might as well say you need a sleep() to store and then access a variable from memory reliably.
I could invent countless examples that show how observations such as you just described do not prove a thing, but I shouldn't have to.
You could say that you observed that when you used a blue container to put gas in your lawnmower, the mower didn't run well. Then you switched to red colored containers and you observed that the mower ran a lot better.
Do you REALLY think that this proves that the red color of the gas can had ANYTHING to do with how well the mower runs?
Or is it maybe that the blue cans had water in them and the red ones didn't? Let a little water get in the the red can and you will discover that the "red can fix" doesn't actually do a thing, even though it looked like it worked 400 times before.
When you sleep, you do give the system more chances for normal continuous/periodic background flushes to occur, but:
* Even if you waited 30 full seconds it's still no guarantee that the writes will be complete. (Translation: Even if you use the reddest can ever invented, it still might get water in it and the mower won't run.)
* If you close the file, then that DOES guarantee that the file is written complete, at least as far as any code running anywhere cares, and it is ready immediately as soon as close() returns. If it takes 30 seconds for some reason, close() itself will be busy for those 30 seconds and won't return until it's job is done, and so it's still true that the very next line of code could be another open() and it will be 100% ready. (Translation: If you check for WATER instead of checking for REDNESS, the mower will always run and it doesn't matter what color the can is.)
Whether you believe it or not, a million bejillion other lines of code all throughout Windows itself, and every other application ever written, absolutely depends on basic functions like this behaving as advertised. They are not adding sleep()'s every time they write a file! Such functions are like the bricks in a house. The bricklayer does not add a metal frame around every individual brick because he has some voodoo idea that since he can't see inside the brick, maybe it's not solid inside there, and so he better strengthen the outside of the brick just in case.
--
bkw
-----Original Message-----
From: "Richard Kreiss" <rkreiss at gccconsulting.net>
Sent: Sunday, September 1, 2013 2:44pm
To: "brian at aljex.com" <brian at aljex.com>, "Richard Kreiss" <rkreiss at gccconsulting.net>
Cc: "filepro-list at lists.celestial.com" <filepro-list at lists.celestial.com>
Subject: RE: create()
A number of us have found that trying to read a file just after a close fails. Sleep nnn paused the processing enough for the operating system and program to get into sync and allow the file to be read or executed.
Richard Kreiss
> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of brian at aljex.com
> Sent: Thursday, August 29, 2013 1:01 AM
> To: Richard Kreiss
> Cc: filepro-list at lists.celestial.com
> Subject: Re: create()
>
> I have not dug into this code, I am just making a tangential remark.
>
> sleep() should be renamed voodoo()
>
> Ok in reality there are uses for sleep(), but sleeping to make sure a
> filesystem operation has completed is pure unadulterated (and inexcusable)
> voodoo.
>
> You either closed the file or you didn't. That's all there is to it. If you closed it,
> then it's ready, for anything, immediately. If you didn't close it, then no
> amount of waiting will ensure it's ready.
>
> --
> bkw
>
> -----Original Message-----
> From: "Richard Kreiss" <rkreiss at gccconsulting.net>
> Sent: Wednesday, August 28, 2013 5:07pm
> To: "filepro-list at lists.celestial.com" <filepro-list at lists.celestial.com>, "Fp
> Support (fpsupport at fptech.com)" <fpsupport at fptech.com>
> Subject: Re: create()
>
> Windows Server 2008
> Workstations Window 7
> filePro 5.6.10
>
> I have a process that creates a batch file. This same processing exists in 2
> programs.
>
> In the original program there is no problem creating the file in rreport.
> However, in the new version, the batch file is not created when running in
> rreport but is with dreport.(used with the debugger to see if the create() line
> is executed.
>
> I am creating an xml file prior to the batch file without a problem. I have a
> sleep "700" after closing the xml file and before creating the batch file.
>
> Anyone have an idea why this works in the older processing table but not the
> new one?
>
> There were major code changes elsewhere in the program which run after
> the create section.
>
> 65 ------- - - - - - - - - - - - - - - - -
> ◄ If:
> Then: declare batfile
> 66 ------- - - - - - - - - - - - - - - - -
> ◄ If:
> Then: batfile="runthis.bat"
> 67 ------- - - - - - - - - - - - - - - - -
> ◄ If:
> Then: aa=create(batfile)
> 68 ------- - - - - - - - - - - - - - - - -
> ◄ If: aa = "0"
> Then: ERRORBOX "(69) RUNTHIS batch File Not Created\n\rSJ
> #\r"<1<"\n\rRecord #\r"<@rn<"\r";EXIT "90"
> 69 ------- - - - - - - - - - - - - - - - -
> ◄ If:
> Then: ex=exists(batfile)
> 70 ------- - - - - - - - - - - - - - - - -
> iIf: @fstat["11"] lt @t4
> Then: msgbox "Runthis.bat file out of Date\nNew File Note
> created\nPress \kZ To Exit";EXIT "90"
> 71 ------- - - - - - - - - - - - - - - - -
> If:
> Then: ab=writeline(aa,FLCMD)
> 72 ------- - - - - - - - - - - - - - - - -
> If:
> Then: ac=close(aa)
> 73 ------- - - - - - - - - - - - - - - - -
> ◄ If: 'pause to give file a chance to close
> Then: sleep "500"
>
>
> Richard Kreiss
> GCC Consulting
>
> Office: 410-653-2813
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
More information about the Filepro-list
mailing list