Status

()

P2
normal
RESOLVED WORKSFORME
17 years ago
16 years ago

People

(Reporter: koehler, Assigned: gordon)

Tracking

Trunk
mozilla1.2beta
DEC
OpenVMS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

42 bytes, text/plain
Details
(Reporter)

Description

17 years ago
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
-> Cache (and confirming because there is nothing to triage)
Assignee: Matti → gordon
Component: Browser-General → Networking: Cache
QA Contact: imajes-qa → tever
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

17 years ago
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

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

Thanks, Colin.
(Assignee)

Comment 4

17 years ago
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.
(Reporter)

Comment 5

17 years ago
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.
(Assignee)

Comment 6

16 years ago
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

16 years ago
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).
(Assignee)

Comment 8

16 years ago
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.
(Reporter)

Comment 9

16 years ago
Created attachment 101690 [details]
 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.
(Assignee)

Updated

16 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta

Comment 10

16 years ago
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?
(Reporter)

Comment 11

16 years ago
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

16 years ago
Bob, any idea when you'll be able to try with V7.2-2 or V7.3-1?
(Reporter)

Comment 13

16 years ago
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

16 years ago
Do you have 7.3-1 yet?
(Reporter)

Comment 15

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

Comment 16

16 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 17

16 years ago
bob: once you upgrade, if this works, please mark this verified. Thanks!
QA Contact: tever → cacheqa
You need to log in before you can comment on or make changes to this bug.