42792 - rdf files written in bin dir

Status: NEW

(Core :: XUL, defect, P3)

Description

[Ben Bucksch (:BenB)]

Split-off from bug 42148. Tracking non-skin files here.
> Split-off from bug 41057. Tracking chrome related files here.

> > If mozilla has write permission to the binary directory it will
> > create/edit/remove the following files.

> > Add:    package/chrome/all-locales.rdf
> > Add:    package/chrome/all-packages.rdf
> > Add:    package/chrome/overlayinfo
> > Add:    package/chrome/user-locales.rdf
> > Add:    package/chrome/installed-chrome.txt

Comment 1

[Ben Bucksch (:BenB)]

Adding to metabug 41057, which is [nsbeta2+].

Comment 2

[David Hyatt]

it only does this as part of the install process.  i believe ben fixed the bug 
where it wrote here if you switched skins.  if he didn't, give him a specific 
bug.

Comment 3

[Colin Blake]

I think this one must have come back. Just fire up Mozilla and exit and I see:

- chrome/all-locales.rdf - opened for write 6 times
- chrome/all-packages.rdf - opened for write 6 times
- chrome/all-skins.rdf - opened for write 16 times

This is with both M0.6 and and M18 builds.

Comment 4

[Peter Trudelle]

->future

Comment 5

[Ben Bucksch (:BenB)]

Trduelle, this bug blocks either bug 41507 or bug 42184, which are both a
mustfix for mozilla 1.0 IMO.

Comment 6

[John Morrison]

Just to be clear, Colin, are you reopening because it opens RDWR (or 
attempts to and falls back to RDONLY), or because it actually writes/modifies
the contents of those files. 

The files noted at the beginning of the bug report will be created as part
of the install process, but as hyatt notes, they will not be subsequently 
modified.

Comment 7

[Colin Blake]

I reopened because the files are being opened for WRITE access, and I
thought it was a goal/requirement that the bin area be read only after
installation.

Comment 8

[Ben Bucksch (:BenB)]

> I thought it was a goal/requirement that the bin area be read only after
> installation.

correct.

Comment 9

[Roland Mainz]

I've added a "workaround" /xfn in bug 41057 for Solaris - is it possible to do
the same somehow in Linux ?

Comment 10

[Colin Blake]

RDF has a class nsOutputFileStream and this calls NS_NewIOFileStream with a file 
open mode of PR_WRONLY | PR_CREATE_FILE | PR_TRUNCATE. This is the place where
all-packages.rdf gets opened for WRITE access.

However, after writing the file, its contents are the same as they were before.
Do I have some other bug on OpenVMS that is causing these files to get 
re-written when really they shouldn't be? Can someone confirm for me that this
is NOT happening on other UNIX based platforms?

Comment 11

[Colin Blake]

Yes, I do have an OpenVMS specific bug here. After spending some time stepping
through in the debugger, I think I know what's going on. The problem is that
the modified time test in CheckForNewChrome is failing and so it thinks there's
new chrome to install. Here's why I think its failing. Assume the following:

open_file_for_read_write   (time=t1)
write_to_file              (time=t2)
close_file                 (time=t3)

Now look at the st_mtime value from a stat call. Does it correspond to time
t1, t2, or t3 on UNIX? I am guessing t1. On OpenVMS its t3. 

Now each time I start Mozilla up it installs the new chrome and I think the
file operations are happening like this:

open installed-chrome.txt
open all-packages.rdf
close all-packages.rdf
close installed-chrome.txt

On UNIX all-packages.rdf will have the later time stamp while on OpenVMS 
installed-chrome.txt has the later time stamp. And so the problem keeps
propagating itself.

Does this make sense to anyone? Can someone confirm the UNIX timestamp
behavior in the above scenario?

Comment 12

[Brendan Eich [:brendan]]

Unix should set mtime based on the time of the last write to the file, not based
on open time.  Nevertheless, given mtime's resolution, I can see how the code
that checks chrome timestamps in Mozilla is buggy.  This is a potentially XP bug.

/be

Comment 13

[Colin Blake]

Right, the mtime resolution is one second, and the comparison in 
CheckForNewChrome is < means "no new chrome" and >= means "install new chrome". 
So if the modified times are within one second, the code will force an install.

Comment 14

[Colin Blake]

I've confirmed that this is indeed the cause of the problem on OpenVMS. Just
by manually setting the modified date on chrome/all*.rdf to the current time I 
no longer see the rdf files getting written to.

Comment 15

[Colin Blake]

This problem was fixed last Friday by the checkin for bug #66450 !!!!

Now we open installed-chrome.txt O_RDONLY and so the race condition goes away.

I think we can put this one to rest.

Comment 16

[Brendan Eich [:brendan]]

Just opening a file for read/write or write, but never actually writing to the
file, should not touch its mtime.  Was it, on OpenVMS?  That seems like a bug.

/be

Comment 17

[Colin Blake]

I believe the time will be modified on OpenVMS, even if the file is not actually 
written to. Its not a bug, just a difference from UNIX.

I'm 99% sure that the time is modified in the file header when the file is 
closed, assuming the file was opened for some kind of write access, regardless 
of if any write ever took place.

Comment 18

[David Hyatt]

--> default owner