>From: Erick Lorenz <address@hidden> >Organization: UC Davis >Keywords: 200103090125.f291PqL26988 McIDAS-X LWPATH.NAM Erick, >I tried to edit my ~mcidas/data/LOCAL.NAM file using emacs. > >As soon as I tried to change some thing I got the following message: > >.../mcidas/data/LOCAL.NAM locked by address@hidden (pid 12208): (s, q, p, >?)? This seems to say that there may be a another edit session of some kind that has/had this file opened. >I assume that address@hidden is address@hidden I would guess that is correct. >There is currently no pid 12208 running. If this is a Linux box, then I would check for the existence of a file in the .../mcidas/data directory named .LOCAL.NAM.swp. 'vi' will create such a file. Notice the leading '.'. The swap file used by the editor will be a hidden file! >Could this be caused by a mcidas session that was aborted rather than >shutdown? No. McIDAS sessions do not use this file at all. The LOCAL.NAM file concept was one I introduced to get folks to take example REDIRECTion entries in EXAMPLE.NAM and edit them to change directory locations to match their setup. >Could it be caused by a mcidas session running on another host which uses this >machine's software and files? No, not by a McIDAS session. Again, McIDAS does not explicitly know about LOCAL.NAM. >Is there a simple way to unlock the file? I am betting that this _is_ on a Linux box, and that there is a .swp file that is/was used by an vi session on this or some other machine. Emacs is probably trying to protect you from editing a file that is open for edit by another editor. Finding and removing the .LOCAL.NAM.swp file should then allow you to successfully edit LOCAL.NAM. If there is no .swp file, then the problem may be NFS related. In this case, the only thing that would make sense is that the file actually resides on a different machine, and somehow it looks locked to your machine. If this is the problem (and I actually have seen this on another users network), it may be an indication of a need for a reboot, or that your system has been hacked (this was the problme on the other users machine). Before worrying too much about a hack, try rebooting to see if the lock goes away. >Thank you Please let me know if either the .swp file or an NFS stale file handle was the problem. Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.