Re^6: Spurious "Invalid Argument" on file open

With the network involved, it doesn't have to be the file that changed. Any temporary resource state in the fabric between you and the actual file could -- breifly -- manifest itself as in an inability to open the file.

That sounds frightening. I didn't expect this ... thought that in this case the underlying software layer (CIFS) would take care about such glitches. Just to get some idea ... what kind of resource state could, for example, cause such an effect?

I think I will follow your suggestion to do a retry....

--
Ronald Fischer <ynnor@mm.st>

Comment on Re^6: Spurious "Invalid Argument" on file open Download Code

Replies are listed 'Best First'.
Re^7: Spurious "Invalid Argument" on file open by BrowserUk (Patriarch) on Oct 24, 2012 at 14:15 UTC
Just to get some idea ... what kind of resource state could, for example, cause such an effect? I don't know much about CIFS, but in general, anything that crosses a network can be subject to temporary timeouts. Take for example, that even in blocking mode, accept() can return without a valid connection for a variety of reasons. Looking at the wikipedia description, Level 2 OpLocks look like a possibility. I'm not sure what timeouts are involved with the SMB protocol, but if the network is heavily congested or the serving node is bogged down, the client could timeout before the server gets around to responding. Any code that deals with a network should allow for these possibilities. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]
Re^8: Spurious "Invalid Argument" on file open by rovf (Priest) on Oct 24, 2012 at 14:33 UTC
if teh network is heavily conjested or the serving node is bogged down, the client could timeout before the server gets around to responding. This indeed could have been the case here! Thanks! -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]