Smalltalk › Instantiations

CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Dan Junker

CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

I am attempting to use CfsFileDescriptor to delete a file and it returns this error: EIO (5) I/O error [32].

If I set a break-point it works just fine so my security is fine and the file is not locked or in-use.

Perhaps setting a 1 second delay would help but that makes me quiver unless it can be explained.

For the record, I am using a UNC name for the filename.

Thanks for any advice!

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/6eOPId8zECAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Wayne Johnston

Re: CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

Guessing my way out on a limb here...

I've suspected a more general problem with UNC paths (shares). We sometimes see evidence of failure to read a file on a share. But the person using that machine can see the file just fine in Windows Explorer (or read the file just fine via Start->Run and specifying the path). I suspect there is some little network glitch where for instance Windows Explorer retries, but VA answers a failure. I wonder if Windows Explorer for instance has some retry, perhaps implying that many methods in Cfs* should have their own retry. It's just a pain to explain to customers that they must have some glitchy network thing going on when they see no other applications having problems. This has happened rarely enough that I don't know how often there's been something bad in the network that was fixed, versus the problem mysteriously going away.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/SIZ-oDtVo5IJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Michael LaMantia

CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

In reply to this post by Dan Junker

What cfs functions precede this call? Are you querying the file before deletion? Is it possible that the delete actually happens before the query completes, rendering a file not found error, even though the file actually deleted? From the little cfs work we do in our application, I know that the file io is very intolerant of anything resembling multithreading or asynchronous calls.

Mike

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Bx_7BRt_ytEJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Dan Junker

CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

Thanks for your response. Before the delete call an external web service converts the file to a PDF, returning the file name of the PDF ... at this point my app is deleting the source file which is no longer needed. One might think that the web service hasn't released its handle to the file .. Or perhaps it did but the network takes time to acknowledge it? ... However, the fact that adding a breakpoint hides the issue indicates that the service isn't to blame.

I played with adding a delay, I had to add a 5 second delay for it to work consistently. I wonder if it would work better if I used a mapped drive letter?

Anyone know what the error code is stating,or is it just a general io failure?

It might be interesting to have the service delete the file, however, that it really not the services responsibility ... From a testing perspective it would still be nice to know as it might prove if the conversion library is not letting go .. I really doubt it is the problem as it is a professional product.

Cheers

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/72LfuOtsSk4J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Dan Junker

Re: CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

In reply to this post by Wayne Johnston

Good thoughts Wayne, thanks, ... For the record I had to add a 5 second delay with a retry to get it to work consistently. See the other post for more details if interested.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/xGp0GxtICEMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Wayne Johnston

Re: CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

Do we know if Instantiations would recommend all VA applications which work with shares - should have such a retry? Or should VA do it for us? Or should Windows handle it? We have a problem right now (reading a file on a share on the server) in an old installation is suddenly sometimes not working for clients in a certain location. I assume it's some network flakiness. It's hard to find things wrong with a packet sniffer. I'm just hoping they start replacing routers etc. until the problem goes away...

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/egK-SjYr6lAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Michael LaMantia

CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

In reply to this post by Dan Junker

Could it be a issue with the Web service sending the file name back on the socket before it closes the source file? Could certainly show similar symptoms.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/MNwRVjAwBN4J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Dan Junker

Re: CfsFileDescriptor delete fails during run-time - works with breakpoint. EIO (5) I/O error [32]

I believe this must be the case Michael ... it seems that network files must be more complicated to close. I can't say that i understand all the differences; however, I know there must be many .... knowing that I did the following:

I went into the conversion service and made a local copy of the network file and passed this file to the conversion service instead of the network file. The service immediately deletes the new local file after the conversion has taken place. After making these changes, the calling Smalltalk code now has no issue deleting the network file (the file it was requesting to have converted) without any inserted delay.

After pondering this some more, I probably could have used a MemoryStream object in the service instead of creating a "hard" local file (avoiding the extra disk activity).

I think we have reached closure here folks; the moral of the story ... avoid complex processing of network based files ... prefer local or in-memory files for the working copy and your days and nights will be happy and full of cheer.

Thanks Michael and everyone else who responded ... it's nice to know that I'm not alone in my cubical ;)

On Monday, December 3, 2012 8:56:42 PM UTC-6, Michael LaMantia wrote:

Could it be a issue with the Web service sending the file name back on the socket before it closes the source file? Could certainly show similar symptoms.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/dihBmeUzxB8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.