How to replace .locked data? 'HIDDEN' locks on File GDBs in ArcPro.

[BrianWoodman]

I work in a shared Government environment using File GDBs on a network drive. No one has administrative rights to install anything or use programs that require elevated permissions (like PSFile or NET FILE). Some users use ArcPro 2.9.3 while others still use ArcDesktop 10.8. We cannot use QGIS or some other GIS.

We do not have the option of installing or maintaining a local SDE.

I have Full Windows permissions on a fGDB. I need to replace the contents of a feature class even when other 'Read-Execute' users have it attached in ArcPro or ArcMap/Catalog. As with many before me, file locks on fGDBs are the bane of my GIS existence. The locks can be obvious (a temporary .lock file exists, created by myself, my script or someone else who is using the same data on their machine) OR the locks can be 'HIDDEN'.
'HIDDEN' locks: In ArcPro, when someone else simply VIEWS the feature class on their machine with Catalog, ArcPro DOES NOT create a .lock file, but nevertheless, the file representing the feature class they are viewing, either a .atx or and .gdbtable(?) file, cannot be tampered with, effectively creating the 'HIDDEN' lock. My assumption is that the file has a hidden process handle attached to it from that person's ArcPro exe. Using shutil.rmtree() leaves behind the files it couldn't delete because of the file handle locks, resulting in a corrupted fGDB.

Question: Has anyone else observed this behaviour of fGDB files that are 'unaccessible' in ArcPro even though there are no .lock files?

Creating a DatabaseView: A way to expose the 'hidden' locks in ArcPro is to first create a DatabaseView from the underlying feature class. These are inherently read-only and created using arcpy.CreateDatabaseView_management(). When the user attaches to the DatabaseView, an .sr.lock file is created. Even with an .sr.lock, we can successfully replace the underlying feature class. This shows great promise BUT, as soon as they open the Attribute table either in their Map or in Catalog using the Table tab, a .rd.lock file is created and we can no longer replace the underlying feature class. This rd.lock makes sense because they are looking at the rows of the underlying feature. Opening the Attribute table in a Map is essential to the user's workflow so we cannot request them to cease and desist from doing that. So, even though we gain the .lock file and the benefit of being able to identify the culprit, this method of creating a DatabaseView in ArcPro DatabaseView fails our purpose.

But perhaps the idea of using a different view of the data for the users is not such a bad one. Is there another format besides fGDB that would allow the ArcPro or ArcMap 10.8 user read-only access and yet allow me to replace the underlying data? Could we keep our operational data in fGDB and replace the data of some other format, something that doesn't use .lock files or that mechanism? Could we use something like the file formats afforded by OGC GeoPackage: .sqlite and .gpkg? Replacing a .sqlite file works fine even when an ArcPro user is viewing the data but it fails if a 10.8 user is viewing it.

If we can come up with an alternative format for posting the final data, are they compatible with both ArcPro and Desktop 10.8? I would love for ESRI to chime in 🙂

Thanks in advance for your help.

Brian