Matfile isn't always finding the file

I'm having a problem using "matfile". There is an inconsistent error, as I described here http://stackoverflow.com/questions/42098631/matfile-isnt-loading-the-structures-field-names

I narrowed it down to the object, matlab.io.MatFile, I get an error in the line

 [varargout{1:nargout}] = fcnHan('-file', ...
                                       obj.Properties.Source, varargin{:})

Saying:

Error using whos
Could not find
\\bontempi...[skip]...NexusMarkersProcessed.mat.

It's weird because it can load just fine, here's some output from my command window during a debug:

 tes=whos(obj.Properties.Source)
 tes = 

0×1 empty struct array with fields:

    name
    size
    bytes
    class
    global
    sparse
    complex
    nesting
    persistent

 >> ves=load(obj.Properties.Source)

 ves = 

struct with fields:

    Patient10: [1×2 struct]
    Patient11: [1×4 struct]
     Patient3: [1×2 struct]
     Patient5: [1×2 struct]
     Patient6: [1×1 struct]
     Patient7: [1×2 struct]
     Patient9: [1×2 struct]

Why can't "whos", see the fieldnames in the matfile object? Why isn't the matfile object loading in the structure?It may have to do with inconsistent behaviour of "exist" on the line:

 itDoes = exist(obj.Properties.Source,'file');

Which when I set a breakpoint there sometimes finds the file, sometimes does not. This may be due to accessing a network drive? Please let me know if there is any more info you need. Thanks

[Geoff Hayes]

Jonathan - if you copy the file from the network drive to your workstation, what happens when you call matfile for the file? Are you able to reliably open/find this file?

[Jonathan Conte]

Yes, it is reliable on the C: drive.

[Geoff Hayes]

I've never used matfile but if it reliably works when the file is local, then perhaps that it is best that you copy the file to your workstation. Or perhaps have IT look at your connection to the network...

[Walter Roberson]

Historically it has been common for programs to have these kinds of problems when working with files on network drives. The networked filesystem is the difficulty.

Networked filesystems are difficult to do really well. They typically have contradictory requirements imposed on them. From the point of view of one client, the networked file system is responsible for providing correct access even in the face of network disruptions. From the point of of another client, the networked file system has to release access to the first client if the first client goes down. The contradiction arises because it sometimes becomes impossible to tell the difference between the first client being down (in which case the server needs to give up on it) and the network having failed (in which case the server needs to preserve state indefinitely to present correct access to the client.)

... and that's without even any consideration of simultaneous access from multiple clients.

[Jonathan Conte]

... my eyes have been opened to the impossibility. Thanks. I'll see if there is a workaround: copying the files to the C: drive at the beginning of the program (assuming I can do that reliably), running it, and finally deleting the temporary copies at the end of the script.

[Walter Roberson]

Copying is almost always reliable in such situations (provided the file is not being written to by a different process at the same time it is being copied.)