155368 - file access conflict

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect, P2)

Description

[Bob Koehler]

We have all file access failures logged on our OpenVMS system.  Everytime I open
a page the security system logs several failures to delete cache files.  I've
checked and the cache files are in fact deleted, so I suspect that there is an
attempt to delete them while they are still open, followed by a successfull
delete (order of operations issue).  We are running Mozilla 1.0 (Build ID
2002053008) for OpenVMS Alpha.
<p>
This is causing a security log to be flooded with unecessary messages.  We
really do want file access failure enabled for security, but would rather
Mozilla did not contribute needlessly to them.
<p>
Here's a sample of the log, with sentitive data edited:

%%%%%%%%%%%  OPCOM   2-JUL-2002 08:23:32.42  %%%%%%%%%%%
Message from user AUDIT$SERVER on <node>
Security alarm (SECURITY) and security audit (SECURITY) on <node>, system id:
<address>
Auditable event:          Object deletion
Event information:        file deletion request (IO$_DELETE)
Event time:                2-JUL-2002 08:23:32.41
PID:                      000003C4        Parent PID:               000003BD
Process name:             VUE$<user>_1    Parent process name:      DECW$SESSION
Username:                 <user>          Parent username:          <user>

Process owner:            [uic]
Image name:               BESSTA$DKA200:[SYS0.SYSCOMMON.][MOZILLA]MOZILLA-BIN.
Object class name:        FILE
Object owner:             [same uic]
Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:
File name:               
_<node>$DKA300:[<user>._mozilla.default.Cache]71B1EF3CD01.;1
File ID:                  (27123,15,0)
Access requested:         DELETE
Sequence key:             0042A5E3
Status:                   %SYSTEM-W-ACCONFLICT, file access conflict

Comment 1

[Matthias Versen [:Matti]]

-> Cache (and confirming because there is nothing to triage)

Comment 2

[Colin Blake]

You are correct, this almost certainly means that there is an attempt to delete
the file while it is still open. While this is a valid thing to do on some
(all?) UNIX based systems, it is not valid on OpenVMS.

Can someone who knows the cache code comment on whether this "delete while still
open" practice is normal and expected (ie. is it designed this way)?

Comment 3

[Colin Blake]

Gordon, if you are not the right person to comment on this can you re-assign?

Thanks, Colin.

Comment 4

[gordon]

Are multiple copies of Netscape/Mozilla being run simultaneously, using the same
profile?  If each copy attempts to use the same cache directory, a conflict will
occur and one instance will delete files the other instance is still using.

Comment 5

[Bob Koehler]

This is not due to sharing profiles.  Every user has his/her own account and
cache path.  The user demonstrating the problem has only one copy of mozilla and
no other browsers running.

Comment 6

[gordon]

The only other possibility that I'm aware of is if the OS leaves the files open
after Mozilla crashes.  When we restart Mozilla, we try to open the files, if we
fail (because some OSs leave them open) we try to delete them and create new
ones.  If we can't delete them, we move them into separate directory and try to
delete them later (possibly a future launch).

Does OpenVMS leave files open if an application crashes?  Do you notice this
problem only after Mozilla crashes?

Comment 7

[Colin Blake]

Mozilla can't leave files open if it crashes. That's impossible on OpenVMS (as
part of image rundown all files opened in user mode are closed).

Comment 8

[gordon]

Bob, could you post a log of all the messages resulting from a single launch? 
I'd like to see if we're having a problem with all the files in the cache, or
just certain ones.  The log message above shows a problem with a data cache
entry file, but I'm wondering if there are problems with map and block files as
well.  I'm mainly interested in just a list of file names that we're attempting
to delete, so I don't need any sensitive data.

Comment 9

[Bob Koehler]

Attachment: none

OpenVMS is rigorous about closing all files when an application exits for any
reason.  We can and have verified that no cache files are open when mozilla is
not running.  It doesn't matter whether the last mozilla exit was normal or a
crash.

The message is logged not on mozilla startup but on page changes (change to new
URL).  The messages all have content similar to what I've already posted.  The
cache file in question did not exist prior to this execution of mozilla so I
think the problem has something to do with creating new cache files, not
cleaning up old ones.

It looks like a delete is being done after a successful open/create.  Perhaps
the status return from the open is being misinterpretted or the OpenVMS C
porting library is returning an incorrect status.  Colin Blake at HP is a good
contact for issues with the porting library.

Comment 10

[Colin Blake]

A recent change to the OpenVMS CRTL allows open files to be deleted (actually,
just marked for delete). Bob, if you have OpenVMS 7.3-1 or V7.2-2 and the most
recent CRTL ECO, can you tell me if you're still seeing this problem?

Comment 11

[Bob Koehler]

I don't have 7.3-1 or 7.2-2.  Im stuck at 7.2-1 for now.  I do typically keep
the CTRL up to date, but if there's a specific ECO youl'd like me to try, let me
know.

Comment 12

[Colin Blake]

Bob, any idea when you'll be able to try with V7.2-2 or V7.3-1?

Comment 13

[Bob Koehler]

Compaq lost track of our maintenance contract and it was never renewed last
year.  We're trying to get this straightened out with HP.

Comment 14

[Colin Blake]

Do you have 7.3-1 yet?

Comment 15

[Bob Koehler]

I have no update on our service contract.  It may be a long time before I get 7.3-1.

Comment 16

[Colin Blake]

I've just tried this myself on a 7.3-1 system and there's no access failures
logged on the cache files. Marking resolved.

Comment 17

[benc]

bob: once you upgrade, if this works, please mark this verified. Thanks!