glenn (08/12/82)
I have a rather lengthy .nfseq file which seems to cause autoseq to die after listing the notesfile name which is at the 255th character in the .nfseq file. It gives "lockn combo lost" message. This problem is readily reproducible, if anyone wants to see it. Any ideas? - Glenn Golden (...vax135!lime!glenn)
ber (08/12/82)
#R:lime:-29100:harpo:18500012:000:84 harpo!ber Aug 12 15:59:00 1982 My .file is 480 characters and I haven't experienced any similar problems. brian
ks (08/13/82)
#R:lime:-29100:pur-ee:13000009:000:203 pur-ee!ks Aug 12 22:49:00 1982 The "lockn combo lost" is usually corrected by removing the (2) lock files in /usr/spool/notes/.locks for that notesfile. Of course you have to be notes guru to do this. Kirk Smith Purdue EE
mclure (03/09/83)
#N:sri-unix:1000033:000:499 sri-unix!mclure Feb 19 23:04:00 1983 Once in a blue moon, autoseq will die with "lockn combo lost". Apparently in misc.c it is looping with a creat() on the particular lock file and sleeping 2 seconds after each failure for a total of 10 tries. It never seems to happen here with notes. Could it have something to do with autoseq not closing its file descriptors appropriately? creat() will fail if there are too many open. Other than that, I can't think of any reason why this should fail occasionally. Anyone have a fix? Stuart