File geodatabase debugging lock problem, what are "rd" locks?

[AlexanderGray]

Hi,
I am currently debugging a problem with locks on a file geodatabase for some functions that were done programmatically.  I notice there are ".sr" locks, which are schema locks, i.e. not change to the schema allowed.  There are ".ed" locks, edit locks, no edits on the data allowed.  There is another lock file, ".rd" lock, this one I am puzzled with.  Does anyone know what rd locks are?  The only mention it would be some unreleased cursor.  Still I would like to know if it puts an edit lock on the featureclass.

[AlexanderGray]

The file geodatabase is not designed to do that.  It is designed do handle multiple readers and one editor.  RDMS geodatabase are specifically designed to do that and esri has SDE for that.  I am not sure what the status for multi-editor on a sql express geodatabase, technically it should work but it may have been clamped down to push users towards ArcGIS server solutions.

[MaryPasse-Smith]

I am having a different but similar problem. I teach in a lab, and occasionally have lock files that persist AFTER ArcGIS is closed, the user is logged off, the computer is rebooted, they are NOT within a file (or any) geodatabase (simply shapefiles that are, often, being joined to something but not always) in a lab setting on a virtual drive, usually. They are so numerous now they are hurting the ability of my students to work--they cannot edit their files, and no way can I save them such that they will work. They are (evidently) SR locks. Nobody can delete them, not even our IT people (I think they had SOME luck in Linux, finally, but it is becoming a real problem). Does anyone know how I can prevent my students from creating these in the first place (may be that they are crashing out, but once they log off, should they not go away??) and/or how to deal with them once they exist? Please help!

[LanceShipman]

Is this on Linux or Windows (version)?

What version of ArcGIS? What product (Engine, Desktop, Server)?

On Windows the lock files are created as "delete on close", so even if the application crashes that files will delete. Windows takes care of it. The only reason a lock file would stay in existence if another process (process, not user) has the lock or if you pulled the pug on the PC. If the lock file is still in existence, the process will normally delete it and create a new one.