Deltas.dat and Contents.####.dat locking error

[ACE001]

We've been seeing this error in all builds of Revit 2016 (BDSP) and I'm hoping someone has some info that may help towards a solution.
We have seen this happen only on new HP ZBook G3 17 (32Gb ram & i7) Win7. The same error occurs on all 3 new machines and we've reinstalled Revit at least once already. The same Revit build on a ZBook G2 doesn't run into the error. Nic drivers are up to date.:

When saving to central Revit pops up the following errors 50% of the time:

We've watched the network activity and it appears that Revit appears to locate the file, start to write to it but then thinks it's locked out and displays the errors. The file permissions don't change from a networking perspective.
Any ideas what this might be and how to solve?

Here's one of the errors showing in the SLOG:
3:< SLOG $9d941183 2016-09-12 11:12:02.426 .STC:Save:Error "Access to \\fcfhphl\network\VH\16-6612\04-models drawings\BIM Models\16-6612-VH Cancer Center_DD_Fitout_Central_backup\contentdocuments.2320.dat was denied."
' 0:< [00001e6c]DBG_INFO: Fatal error (64) when writing to Slog.: line 2143 of Worksharing\WorksharingLog.cpp.

[Steve_Stafford]

You don't say what action generates this message; opening the local file, using Sync with Central etc.

These three things I'd check more closely:

• Sufficient space in the user temp folder to write files. When this folder location runs out of space strange errors are know to occur.
• Revit Server? - If so this can indicate temporary disconnection between host and accelerator. Usually a successful synchronization can occur a few minutes later.
• When a local file is created is the user choosing Append Time Stamp or Overwrite? I've seen weird file write/access errors when the file started out being overwritten and then later switched to Append timestamp. It seems that it may relate to the above temp file space issue or just that Revit is looking for a previous file's backup folder but doesn't have permission to rename it.

[ACE001]

Sorry, We're not using Revit server. And it happens when they Rtc.

[Steve_Stafford]

Okay, still sounds like a network issue...related to something unique about the three PC's you've noted. You haven't provided any clues about your network infrastructure. As much as you'd like to be able to absolve it from blame Worksharing and Revit can't be separated from the network supporting it. It taxes a network like no other office related software does. The messages suggest user permission issues to me.

[digihumminbird]

I would take a look at the Journal files for the users and see if the path to the central files match in the Journals. And, see what the Journals tell you there, sometimes there are tiny clues about networking, path errors, etc.

What Steve said about memory could be the crux of the matter. While Revit is reporting the error writing to the Server, it actually may not be able to communicate data from the Local to the Server if the Local is stressed to capacity (nothing to write).

I would try to see if you can isolate when the errors occur by breaking down the Sync process manually into it's separate parts:
(1) Save Local [CTRL + S] - Any errors?
(2) Reload Latest [RL] - Any errors?
(3) Synchronize - Still errors?

Then, re-check the Journals.

Your file paths look okay (150 characters or less), but it's also possible that under the hood, depending on your networking configuration (especially if using virtual servers) that Revit is "seeing" more information than the Windows session "sees," and if you're getting close to that 250 character count, it could be causing the errors.

Last, and this one is a humdinger, get under the desk and check the cords and ports... I've seen these exact same errors on towers where the wall jacks were damaged and the slightest vibration on the floor (desk chairs on hard surfaces rolling past) caused the cord to jiggle ever so very slightly. And, real story, I had one user who nervously tapped his foot against his tower while he waited on a STC. He was seeing these types of errors daily every time he Synced to Central and was ready to quit, thinking the project was too large for his machine. My whole IT team was stumped for weeks until we spotted the pattern. This kept happening until we literally duct taped his ports both on his tower and into the wall (and put his tower up on the desktop, away from his nervous feet).