| Title: | PATHWORKS for OSF/1 |
| Notice: | see also NOTED::PWDOSWINV5 (PW client) & TURRIS::DIGITAL_UNIX |
| Moderator: | CPEEDY::LONG |
| Created: | Thu Apr 22 1993 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1874 |
| Total number of notes: | 6870 |
Hi,
I have a cust who is seeing the following prob using DEC OSF/1 V3.2A
and PATHWORKS for Digital UNIX Version 5.0G ECO2.
Client has a problem writing to a file. The sequence of events are:-
Client creates a temporary file called usrtemp.
Starts reorganising cc:mail post office file, writing the contents to
the temporary file.
Renames the temporary file to the name of the original master.
The process bombs out with an error and the administrator cannot move
or delete the usrtemp file. Pathworks does NOT see the file as being
open (net files) yet I can see that it is an lmx.srv process that is
holding it open (lsof).
This has happened a few times in the past and we upgraded Pathworks and
re-created the accounts.lmx database. The files are always zero bytes
in size, so it would seem the client never actually gets to write to it
after the file creation.
Is there any way of closing the link from the lmx.srv process?
Is there a way of stopping this for good?
I think that this is something to do with file caching but as this is
done more from the OS than PW I am not sure how to stop / modify the
use of open file cacheing.
Does this seem like a probable cause of this or is it some thing totaly
different that could be causing this problem
Help Trev UK CSC.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1827.1 | me too | EVTAI1::CASTELLO | UNIX and PCI Support | Wed Apr 23 1997 15:21 | 21 |
Hi Trev I just have a very similar problem. This happens since the newly upgrade to V5.0G-ECO2. The customer sees it with Audora pro mail application. He can't open files because they seems locked but net file shows nothing. lmstat -f gives more information and we can see the inode and retrieve them. The PCs are WIN95 and the share is Advfs FS. What I've done (untill the next) is under Unix to rename file (mv ..) then copy it back with the original name.(so the inode has changed). Stop and start PCs does not help. Could you post or mail me the lmstat -f if the pb is persistant and reproducable at will. Is there another way to reproduce the symptom ? Thanks, Jean-Pierre | |||||