Error when replacing fob on export

vaprog

I suffer from the following annoying condition and hope someone knows a cure.

Whenever I export objects from the Object Designer, or export files using dataports, and I choose an existing file on the network to be overwritten, I mostly, but not always, get an access error, after I have confirmed to overwrite. I just have to take a second attempt. This time the file has been deleted already and the export succeeds.

The error message states the following (back-translated):

The operating system cannot access the file <file>.
Please check the file's type and attributes.

So it looks like a race condition. NAV seems to attempt to create the new file before the network file server has deleted the file.

The issue seems to be independent of the NAV client version, but dependent on either the Windows client version or the file server version. The fact that this occurs not only on windows servers, but also on Linux based NAS storage, suggests, that this is an issue with the Windows client (some Windows 7 variant).

I am unsure whether I get the error rarely or never when saving to local storage.

Is there some compatibility setting for the NAV client executable or some setting for the network to adjust to get rid of this annoyance?

vaprog

Do you not experience this condition or do you just not know any cure? Please respond, if you experience this. Even to know, that someone else has to deal with this might provide some consolation. Also to know that most of you don't experience it will tell me that it might be worthwhile to pursue the case to find some setup that does not trigger the error.

My coworkers, don't have the problem, I had it even at different sites. I tried to disable any special non-microsoft programs I tend to use, but the problem persists.

I used Sysinternals Process Monitor to confirm my suspicion that the error is caused by a pending delete state (The system cannot create the new file because it did not carry out the previous delete even though it returned success on the delete call). Since this is by design of the OS/FS, I really wonder why I should be the only one to suffer from this issue. The only cure I know of is to handle the overwrite differently in programming (i.e. the NAV executable should handle it differently).

The issue is present in NAV 2013 Build 7.00.33781 Development environment), NAV 2009 R2 Build 6.00.34699 and likely any other build.