Weird handling of openfiles (was Issue with opening PDF file from FilePro)

[Brian K. White]

Boaz Bezborodko wrote:
> -------------------------------------------------------------------
>   
>> Message: 1
>> Date: Wed, 27 May 2009 18:49:42 -0400
>> From: "Brian K. White" <brian at aljex.com>
>> Subject: Re: Issue with opening PDF file from FilePro
>> To: filepro-list at lists.celestial.com
>> Message-ID: <4A1DC386.9070507 at aljex.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>
>> Boaz Bezborodko wrote:
>>   
>>     
>>> 2.  How do I check if a file can be opened in R/W mode in FP?
>>>
>>>     
>>>       
>> ....
>> then: form foo{""
>> then: printer reset 'release the print job so printwizard can take it
>> then: gosub waitpdf  ' wait for pdf to exist and become writeable
>> if: pdfok
>> then: system "start" < tempfile
>> if: not pdfpk
>> then: errorbox "Output ("{tempfile{") not created."
>> ....
>>
>>
>> waitpdf if:
>> then: cs(4,.1)="0" ; c(3,.0) = "300"  ' c*100msec = timeout (300 = 
>> 30,000 = 30 sec)
>> wploop if:
>> then: cs = c/"10" ; show "Waiting" < cs < "for PDF..." ; handle = 
>> open(tempfile,"wb")
>> pdfok if: handle ge "0"
>> then: close handle ; goto ewp
>> if: c gt "0"
>> then: c = c - "1" ; sleep "100" ; goto wploop
>> ewp if:
>> then: show "" ; return
>>
>>
>> basically, as per the open() documentation:
>> "If the file cannot be opened, a negative number is returned."
>>
>> So, try to open() in write mode, then see if handle is a negative number.
>> As soon as handle is 0 or greater, close(handle) and proceed to use 
>> tempfile.
>>
>> The rest of the stuff is just nice user display and timeout so that it 
>> won't wait forever if there is some problem and the pdf will never show up.
>> Don't think that 30 seconds is too long. The user would only ever wait 
>> that long if the pdf generation failed and the pdf will never show up.
>> So you don't want to wait forever and force the user to break out 
>> ungracefully, and you also don't want the "I give up waiting" time to be 
>> shorter than the worst possible legitimate scenario of a very slow pc on 
>> a slow network trying to produce a huge report. That could even be 
>> longer that 30 seconds.
>>
>> You can even get fancier and return a more informative error message by 
>> returning the actual error code from handle instead of just waiting for 
>> handle to be 0 or greater.
>> ie: when handle is a negative number, it's a negative version of the 
>> value returned by the OS's open file function. These numbers are defined 
>> somewhere (msdn web site?) so a -2 may mean file not found or a -5 may 
>> mean insufficient user priviledges, etc... and add in some abort key 
>> handling so they can also break out of the wait loop gracefully.
>>
>>   
>>     
> I put variations of this code to work and on some machines it still 
> didn't work.  I realized that there was a pattern...The machines on 
> which it worked before still worked and those that didn't still had the 
> same problem.
>
> I decided to peek into what the different machines showed as the file 
> status that was returned by OPEN() and found that the machines that had 
> the problems always returned a 'valid' file handle ('1' ) even though it 
> was not possible for it to be available from the very beginning.  The 
> machines that worked gave a negative number until the file was ready.
>
> All are connected to the same server and have almost identical 
> environment setups.  I'm at a loss in explaining why some machines are 
> properly reporting the file status while others aren't.  It must be 
> related to Windows, but I have no idea where to look.
>
> Does anyone have any suggestions?
>
> Boaz

That is extremely interesting.
And no I have no idea why the OS would say "sure that file exists and 
you can even open it in write mode"
when the file was locked by something else or didn't exist and you 
didn't request open() to create on the fly if not exist by having a "c" 
in the mode flags.
(you didn't have: handle = open(file,"wcb")

I would set up a test where instead of trying to open a printwizard 
file, have a filepro process open a file that does not exist, in write 
mode, without "c"
Does it succeed? Does the file actually get created or did fp just think 
it did?
If so then for some reason Windows is satisfying open() requests as if 
you had asked it to create on demand, even when you did not ask to 
create on demand.
You can probably work around that by inserting a seperate exists() test 
before to open() test, but inside the same loop.
exists() should definitely always fail if the file doesn't exist. If 
exists() fails then you skip the rest of the loop, except do the sleep 
and decriment the counter, do NOT do any open() for that iteration of 
the loop!
if exists() succeeds then you proceed to the next line which is the 
open() test, and the rest of the loop as normal.

That covers the case where the file didn't exist, but windows created it 
on the fly, and therefore you are _always_ able to place the write lock 
on a file you just created yourself.
Next do a similar test but where the file definitely exists, and 
definitely is locked.

This time have a filepro process open a file in write mode, with "c" in 
the mode flags to create the file intentionally and lock it at the same 
time.
Have that process pause at a msgbox after opening the file in write mode.
Then have another fp process attempt to open the same file also in write 
mode.
Does the 2nd process succeed? That should definitely never be possible. 
That's a broken OS.

Except.. maybe Vista's user seperation virtual filesystem stuff can 
cause this.
I know very little about it, but I have heard that in Vista you have to 
do something special for shared/common access to files where the locking 
matters, such as database files in legacy apps not written specifically 
for Vista, which is exactly the case here.

I would also investigate the possibility of network filesystem client 
caching effects if any of this is happening on a network drive.
Maybe try the above tests with the temp file on the C drive if they 
weren't already.

-- 
bkw