.lck files not automatically deleting

[AndersonEconGroup]

We save all of our .fm book and chapter files to a central server, and recently we've noticed that when we close a file the .lck file does not automatically delete. Thus, we are having to manually delete this before updating books, opening files, etc. We're using FM8 on PC's with Win 7 x64. We have FM set to run in XP x32 compatability mode, which is working pretty well for us aside from the aformentioned issue.

Has anybody else run into this? Any ideas on a fix?

Thanks! Scott

[Art_Campbell1]

I haven't run into this, but the first thing I'd check is the network / server permissions.

I suspect the local system, or the owner of the local copy of Frame, or the local user, doesn't have permission to delete system files on the server.

Related to this, you may want to confirm that your copies of Frame have preferences set to match whatever OS is running on the server, not the local machine.

[Jeff_Coatsworth]

I've seen it happen with a Vista machine in our operation too - I had just put it down to not closing the files the operator was working on first before closing FM. Their normal habit was just to close the application & say yes to the save prompt, but that seems to have left .lck and .auto files on the server. Taking their time to save & close each .fm seems to have fixed it.

[TimLMun]

We have the same issue, but ours is a bit more sporadic. When I open FM files on our server, and then save and close the file, it sometimes remains locked. The next day, I can be the one who attempts to open the file, and I see a message that says I am the one who has the file open. I cannot be 100% certain without placing a camera on my shoulder, but I am very confident that I *always* close the file in FrameMaker prior to closing FrameMaker.

[Jeff_Coatsworth]

@Tim - I still see it happening once in a while (usually when updating a book). My suspicion is that it's a Windows server issue - W2K3 and W2K8 versions have known issues with leaving files hanging long after the user has logged out & shut down for the night.

[Bob_Niland]

Do the lock files actually still exist?

If you're discovering them because FM is complaining on open, then yes they effectively still exist (although possibly only in server FS cache).

But if you're merely seeing them in a file browser, they may or may not be there. Doing a refresh may or may not clear up matters,

Browser currency is a fundamental, and probably intractable, problem in computer science. Many OS'es don't even attempt to keep track of multiple local and remote browsers that presently have a dir open, much less asynchronously force-refresh them when the dir contents change. Windows tries to, with an assortment of performance, nuisance and failure modes.

I blame Bill Gates.

Reboot the server .