cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Lock file problem

Highlighted
Newbie

Lock file problem

I have run into a strange problem:

We have a function in Adept that allows opening non-sgml files by
unpacking and creating an SGML file in the /tmp directory. We then
disable the Save menu and toolbar button so that the user is forced
to use SaveAs if he really wants to keep the document. We also
install a callback for doc-destroy that cleans up the /tmp directory.

All the code works fine including the callback, which calls "remove_file".
However, if the same source file is reopened, our function creates a
new unique directory in /tmp (based on getpid() and elapsed_time() ),
and tries "edit -nw". We now get a message that the file is being edited
by another user with the usual "respect, override or cancel" option.

This is surprising since the first time the full pathname is
/tmp/sdif2933395362/tstdoc/tstdoc.sgml (which works), the second
time it is /tmp/sdif31793515/tstdoc/tstdoc.sgml, which gives the
message.

First of all I do not understand what is going on since the filenames
are different and second, I cannot figure out a reliable way to find
the associated lock-file to a particular document (so I can remove it).

Curiosly, this problem only appears as long as I retry within the
same session. If I restart Adept and then try again, there is no problem
the first time. Subsequently the same problem appears.

The only function I could find that manages lock files was a shell
script, "publocks -rm", but this is overkill since it deletes all
my lock files, furthermore it unacceptably slow if there are a lot
of lock files.

Does anyone have an idea of what is happening, and particularly
how I can get rid of the specific lock file ?

Regards,
Per-ÃÂ
ke
--
Per-ÃÂ
ke Ling (note: Per-Åke, transliteration Per-Ake)
email: Per-Ake.Ling@uab.ericsson.se phone: +46 8 727 5674
Ericsson Utvecklings AB mobile: +46 70 790 2446
AXE Research and Development fax: +46 8 727 3463
Tags (2)
2 REPLIES 2
Highlighted

Lock file problem

> From: Per-Ake Ling
...[snip]
> Does anyone have an idea of what is happening, and particularly
> how I can get rid of the specific lock file ?

I am still not sure what is happening but I believe I got rid of the
lockfile with the following code (called from the "destroy" callback):

local lockfile = main::adept_path."/locks/".basename(tmpname).".";
lockfile .= `ls -i $tmpname | awk '{ printf $1"\n"; }'`;
if (access(lockfile,"e")) {
remove_file $lockfile;
}
remove_file -r $tmpdir;

I did remember seeing some postings far back that mentioned that
the lockfiles use the inode as part of the filename, and the above
code is based on that. It seems to work.

Per-ÃÂ
ke
--
Per-ÃÂ
ke Ling (note: Per-Åke, transliteration Per-Ake)
email: Per-Ake.Ling@uab.ericsson.se phone: +46 8 727 5674
Ericsson Utvecklings AB mobile: +46 70 790 2446
AXE Research and Development fax: +46 8 727 3463
Highlighted

Lock file problem

Per-ÃÂ
ke,

I believe that the reason it may think it's the same file is because the locks
are keyed in to the inode of the file, and if the inode *and* the process ID
are the same, it may think it's the same file. Further, assuming you're using
Solaris, the fact that Solaris merges /tmp and swap may have something to do
with the problem.

Possible things to try out would be: not using /tmp; opening a *random*
(but small) number of zero-length files in /tmp prior to opening the tstdoc
file (so as to get a different inode) and then closing them.

Sorry I can't be of more help. Ah, regarding unlocking the file, get the inode
number of the open document (ls -i) and look in ${APTPATH}/locks for a file
that ends with that number. Make sure it has the same name as the document in
question (since different files in different file systems may conceivably have
the same inode number), and remove the lock file.

Eduardo
Announcements