File error -43 on a file that's really there

Jeffrey Kain (11/12/08 10:12AM)
psmith (11/12/08 10:37AM)
Jeffrey Kain (11/12/08 11:34AM)
psmith (11/12/08 4:29PM)


Jeffrey Kain (11/12/08 10:12 AM)

<EB8EBE254C16534D9BC41A91DAECF87804B525D1@...

Thanks - I'm going to try to reproduce it some more here, but so far I

cannot make it happen on my XP system.

Jeff

-----Original Message-----

From: psmith

Sent: Wednesday, November 12, 2008 4:37 AM

Jeff,

I wasn't able to nail down why this is happening. I'll put in a test  

of the pathname and see if it gives me a -43 also.

psmith (11/12/08 10:37 AM)

Jeff,

I have a user who has intermittent problems similar to what you  

describe.  In our case, accessing the files generates an error -1,  

which is supposed to be an error from the resource manager but is  

apparently some kind of generic failure. If the file didn't exist, I  

would expect something other than -1, say -38, -40, -43 or -45. It's  

as if the file was there but the OS can't acess it for some reason.  

However, we don't test the pathname before trying to access the file  

- we just create it and use it...

It happens when creating text files of a few hundred kb from a stored  

procedure, then sending them to the client machines. The files get  

created fine but sometimes they can't be "found" to be sent to the  

client. Usually, the user can try again later and everything works  

fine. I suspect something is happening with the Windows file manager  

not keeping things up to date or perhaps somehow 4D is not using up-

to-date directory information but that's just speculation.

Environment is Win 2003 server, 4D 2004.4 (yeah, still an older  

version, but the customer doesn't want to upgrade...).

I wasn't able to nail down why this is happening. I'll put in a test  

of the pathname and see if it gives me a -43 also.

P. Smith

TSE International

Hey all,

Here's a strange one.

I spent most of the day today trying to track down a problem at a  

customer's

site, and it sure looks like Test Path Name is failing. This is 4D  

2004.6 on

Windows XP.

The code in question does the following:

 - Creates a PDF file using Win2PDF

 - Tests that the file exists

 - Moves the document to a blob

The code fails in the 2nd step when it calls Test Path Name. The  

document

does in fact exist (we can see it in the temp directory where it  

should be),

but the command returns -43. It only fails when the PDF file is  

large (about

700K-1MB). Small files are fine and are processed by the same code  

all day

long with no errors. The code in fact calls Test Path Name upto 50  

times

before giving up with a 25 tick pause in between tries just in case

antivirus or indexing software is preventing us from accessing the  

file.

Has anyone ever seen Test Path Name fail like this?

Jeff

Jeffrey Kain (11/12/08 11:34 AM)

<EB8EBE254C16534D9BC41A91DAECF87804B52674@...

Well, the customer made a file 10x larger today and the old code worked

fine. I guess we'll watch this for awhile and see how often this

happens...

psmith (11/12/08 4:29 PM)

Jeff,

I was thinking we might try to perform something else on the files,  

like SET DOCUMENT PROPERTY, regardless of whether the pathname is ok.  

It would be a way to see if some 4D commands work, even if the  

directory information doesn't seem to be up to date. I would think it  

might. After all, we were able to create the files and stuff data  

into them, then close them.

P. Smith

TSE International

Thanks - I'm going to try to reproduce it some more here, but so far I

cannot make it happen on my XP system.

Jeff

Reply to this message

Summary created 11/12/08 at 12:05PM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com