It's all about the answers!

Ask a question

scm daemon not releasing handle on work dir of lscm

Balz Guenat (1513) | asked May 16 '18, 9:22 a.m.

When I execute an lscm command (e.g. lscm --version) in some working directory, the spawned scm.exe daemon obtains a file handle on that working directory which it does not release, preventing the deletion of that directory.

Is this behavior intended? If yes, why?

Karthik Krishnan commented May 17 '18, 9:04 a.m.

I have seen this behavior with lscm and not scm.exe.

Not sure if usage of SCM.exe is Ok for your use case

Balz Guenat commented May 17 '18, 10:41 a.m.

SCM.exe would be a hassle.

During our build, an analysis tool (Sonar), or rather a plugin thereof, calls lscm annotate on all source files. The tool has no configuration option to change lscm to scm. Such a change would require us to edit the source code of the plugin (thankfully open source) and build our custom version.

Even if successful, this solution is unattractive for performance reasons. As stated above, the tool calls annotate on every source file. I understand that batch jobs like these are the main use case for lscm over scm.

One answer

permanent link
David Lafreniere (4.8k7) | answered Jun 01 '18, 2:53 p.m.

'lscm' keeps the daemon running, which is why it is more performant than using 'scm'. At the end of your script (if you are done with the 'lscm' commands / done working with the current sandbox), you could try the 'daemon stop' command and see if that frees up the locks you are seeing.

Balz Guenat commented Jun 18 '18, 2:51 a.m.

Thanks for the answer. This is what I've been going with thus far but I consider it a workaround.

I get why the daemon keeps running but I see no reason why it should be keeping these file handles. Furthermore, making it the build script's responsibility to stop the daemon isn't very elegant, considering that it shouldn't even "know" that lscm is being called.

Your answer

Register or to post your answer.