Last Comment Bug 322304 - editparams.cgi won't save updates
: editparams.cgi won't save updates
Status: RESOLVED WORKSFORME
:
Product: Bugzilla
Classification: Server Software
Component: Administration (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: default-qa
Mentors:
: 336146 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-03 20:58 PST by Mike Partain
Modified: 2015-11-18 21:25 PST (History)
5 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Mike Partain 2006-01-03 20:58:16 PST
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)
Build Identifier: 

Default values are always shown on editparams.cgi page on an IIS installation. Other portions of the system seem to be operating correctly.
Using bugzilla ver 2.20

Reproducible: Always

Steps to Reproduce:
1. goto editparams.cgi
2. Change any field(s)
3. save changes
4. return to editparams.cgi, notice old values



Expected Results:  
Expected updates to be saved and used

IIS install
Comment 1 Frédéric Buclin 2006-01-04 03:24:28 PST
To know if values have really been saved, you should get a list of changed parameters when you click "Save". If you see no list, then they haven't been changed.
Comment 2 Mike Partain 2006-01-04 06:15:44 PST
As a test, I just changed UseMenuForUsers: results;

Saving new parametersChanged usemenuforusers.

OK, done.

Then, editting an existing bug, there were no user menus.

So even if it is being saved, the new value is not being used and it makes it difficult to use editparams again since all values reset. I doubt if its being saved. Permissions are correct on the folder. I can see various params.* files in the Bugzilla data directory including one that has the modified parameter, but the param file with no extention has not been changed.
Comment 3 Mike Partain 2006-01-04 06:21:44 PST
Follow; I renmaed the latest params.#randomchars# file to 'params' and the new values took effect. So something is happening when the server tries to rename/move the new parameter file to 'params'
Comment 4 Frédéric Buclin 2006-01-07 07:03:21 PST
(In reply to comment #3)
> Follow; I renmaed the latest params.#randomchars# file to 'params' and the new
> values took effect. So something is happening when the server tries to
> rename/move the new parameter file to 'params'

As far as I know, Bugzilla doesn't rename data/params. Could you make sure that its permissions are correct?
Comment 5 Mike Partain 2006-01-07 15:06:32 PST
Already checked them."Permissions are correct on the folder". Bugzilla might not be renaming, but something in the code path is - perhaps Active Perl. Like I also said, the current 'work around' is to do editparams.cgi, then go to the directory, delete params then rename the latest params.random_extension to params.  This will make the params take effect and they will also populate the editparams properly next time you edit.  Just as a side note, if permission were a problem it would not be writing the params.random_extension file, which it is correctly.
Comment 6 Olav Vitters 2006-01-07 15:16:31 PST
(In reply to comment #4)
> As far as I know, Bugzilla doesn't rename data/params. Could you make sure that
> its permissions are correct?

It creates a data/params.XXXXX tempfile (with all the X characters being replaced with a random number). See Bugzilla/Config.pm, WriteParams.
Comment 7 Frédéric Buclin 2006-01-08 05:50:13 PST
(In reply to comment #6)
> It creates a data/params.XXXXX tempfile (with all the X characters being
> replaced with a random number). See Bugzilla/Config.pm, WriteParams.
> 

Yes, you are right. I just noticed it right now:

    rename $tmpname, "$datadir/params"
      || die "Can't rename $tmpname to $datadir/params: $!";

    ChmodDataFile("$datadir/params", 0666);


glob, is it possible that there is a problem with rename() on Windows?
Comment 8 Mike Partain 2006-01-08 09:34:26 PST
also fyi additional info; I had a V2.18 running on windows under apache and did not have this problem.

As far as a rename, it looks to me like Unix rename is acting more like a move, being able to change directories as well as overwrite the existing file.  In windows, I think renames acts more like a rename, and expects only the filename to change and no collision with an existing file. I personally added an unlink, and changed the rename to just the name portion in the perl file - but it didn't work. But that was the first two lines of perl I ever used in my life so I don't put a lot faith in them.
Comment 9 Colin Ogilvie [:cso] 2006-01-08 14:25:30 PST
Which version of IIS?
Comment 10 Mike Partain 2006-01-08 14:36:03 PST
IIS 6
running on windows 2003 server
Active perl 5.8.7 w/14 patches

I don't think IIS has any influence - seems like a 'use of rename on windows' issue.
Comment 11 Byron Jones ‹:glob› 2006-01-08 17:15:17 PST
> Yes, you are right. I just noticed it right now:
> 
>     rename $tmpname, "$datadir/params"
>       || die "Can't rename $tmpname to $datadir/params: $!";

ah, well that code's wrong.

|| should be "or", or the arguments to rename should be in brackets.

> glob, is it possible that there is a problem with rename() on Windows?

no. 


mike -- can you please fix Bugzilla/Config.pm so the lines say:

  rename $tmpname, "$datadir/params"
    or die "Can't rename $tmpname to $datadir/params: $!";

then at least we'll get the reason for the failure.
Comment 12 Mike Partain 2006-01-08 19:07:01 PST
Software error:
Can't rename data\params.Mf6sO to ./data/params: Permission denied at Bugzilla/Config.pm line 296.
For help, please send mail to this site's webmaster, giving this error message and the time and date of the error. 

[Sun Jan 8 22:03:26 2006] doeditparams.cgi: Can't rename data\params.Mf6sO to ./data/params: Permission denied at Bugzilla/Config.pm line 296. 

--------

Keep in mind I would expect that since a file with the new name already exists. I have trippled checked the permissions now too, btw, so please don't ask :)
Comment 13 Byron Jones ‹:glob› 2006-01-08 19:13:34 PST
> Keep in mind I would expect that since a file with the new name already exists.

nope - rename will clobber any existing file.

> I have trippled checked the permissions now too, btw, so please don't ask :)
 
are you using cygwin or activestate perl?
Comment 14 Mike Partain 2006-01-08 19:57:16 PST
it might be ok to rename in Perl, but it is NOT OK in windows;

C:\>dir *.xml
 Volume in drive C is DRIVE_C
 Volume Serial Number is 081B-8797

 Directory of C:\

12/31/2005  07:55 PM             1,244 t.xml
12/31/2005  07:55 PM             1,244 t2.xml
               2 File(s)          2,488 bytes
               0 Dir(s)  45,259,968,512 bytes free

C:\>rename t.xml t2.xml
A duplicate file name exists, or the file
cannot be found.

C:\>
--------------------
I am using Active State Perl 5.8.7 w/14 patches (mentioned earlier)
Comment 15 Mike Partain 2006-01-08 20:28:35 PST
Active Perl rename uses MoveFileEx() API, not Rename - so you're right, in perl the rename should work.
Comment 16 Marc Schumann [:Wurblzap] 2006-01-09 01:24:08 PST
Is this really IIS only? It seems to be a perl thing from what I gather, so it can happen with Apache, too, right?
Comment 17 Mike Partain 2006-01-09 05:30:27 PST
I can confirm it happens in apache also.
I previously ran 2.18 in apache and things were ok. Just switched to 2.20 in IIS and noticed the problem, and so reported it as IIS.
I just started apache with 2.20 and have the SAME error.
Comment 18 Frédéric Buclin 2006-01-09 10:37:48 PST
Note that the code in Config::WriteParams didn't change since 2.17.7. So if the bug is real, the reason is somewhere else.
Comment 19 Marc Schumann [:Wurblzap] 2006-01-09 11:03:23 PST
(In reply to comment #12)
> Software error:
> Can't rename data\params.Mf6sO to ./data/params: Permission denied at
[...]
> I have trippled checked the permissions now too, btw, so please don't ask :)

I can't find a way to reproduce this error, neither with Cygwin nor with ActiveState.

If you get a "permission denied" error when renaming, then there is something keeping your params file from being overwritten. If you say it's not permissions, is there perhaps an editor locking it? What happens if you try to overwrite it from the command line, along the lines of "copy params.sdgzsvnd params"?
Comment 20 Marc Schumann [:Wurblzap] 2006-01-10 05:36:29 PST
Fwiw, there is a posting on support-bugzilla@ which looks similar to me -- it's about a versioncache temp file not getting renamed correctly.
Comment 21 Richard Kerry 2006-01-10 06:02:28 PST
(In reply to comment #12)
> I have trippled checked the permissions now too, btw, so please don't ask :)

You say you've triple-checked the permissions, but what have you checked that the permissions are ?

The reason I am asking this is that I seem to recall having the same problem and it was because the permissions given in the Windows install document are not correct.
The document (IIRC) says to set the security on bugzilla/data to permit the Internet Guest account Write access.  I found that this was not sufficient and it also needs Modify access.
Have you done this ?

Comment 22 Mike Partain 2006-01-10 06:50:16 PST
OK - I've said it worked OK in 2.18, so apparently permissions were ok there, I know how they are supposed to be. I've said I checked the permissions three times, I've been ask to check them again. I've said i know how to work around the bug. So at this point I have lost interest in working the problem. It will crop up again with someone else i'm sure.

One thing you guys need to do is READ THE PREVIOUS COMMENTS AND QUIT ASKING THE SAME QUESTIONS.
Comment 23 Max Kanat-Alexander 2006-01-10 11:44:52 PST
If it's still a problem, it's not a WONTFIX. Reopening.

At the least, this is a fairly commonly-reported issue and we should make a docs note about it, perhaps.
Comment 24 Matthias Buchebner 2006-01-11 02:27:04 PST
(In reply to comment #20)
> Fwiw, there is a posting on support-bugzilla@ which looks similar to me -- it's
> about a versioncache temp file not getting renamed correctly.
> 


Hi, 
to explain it a little bit:
when I don't log in for a longer time (let's say a day or something), and then I search for a bug, I get the following error message:
Software error:

Can't rename data\versioncache.NJ8EB to versioncache at globals.pl line 312.

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.
[Wed Jan 11 10:54:09 2006] query.cgi: Can't rename data\versioncache.NJ8EB to versioncache at globals.pl line 312. to versioncache at globals.pl line 312.


In the data directory, I see a file that is called: versioncache.NJ8EB and one that is called versioncache.
I believe there is some pathname conflict, because when I run the following test script, it works:

rename ("C:/bugzilla/data/versioncache.NJ8EB","C:/bugzilla/data/versioncache") 
|| die "Can't do that";

So the key to the problem must be somewhere in the pathname, I guess the same is true for the "params"-problem.

cheers
Matthias
Comment 25 Matthias Buchebner 2006-01-11 03:58:24 PST
Hi, I guess I fixed it, I tried to edit the params, and they didn't get lost. It is a pathname-problem.
What I did is: *edit the file Config.pm
*edit the variable libpath from "." to your bugzilla-installation path (e.g. "C:/bugzilla".
That's all!
works fine for me.

Please test it!
Cheers,
Matthias
Comment 26 Richard Kerry 2006-01-11 04:10:50 PST
I asked Mike how he'd checked the permissions as I've concluded that 'write' is not sufficient to do a rename on Windows, 'modify' is needed as well.  He did't state how he'd done this check and I can't find the text 'Permissions are correct' (referred to in comment #5) anywhere in the Bugzilla tree.
Could someone please point me to where this text is found, which I am assuming comes from a check within Bugzilla (called from checksetup ?), so I can try to see if the absence/presence of 'Modify' is reported correctly.
The only permission references I can find in checksetup.pl appear to be in the Unix numeric format, which (as far as I recall, I'm a Windows not a Unix user) doesn't distinguish between write access and modify access.
Comment 27 Byron Jones ‹:glob› 2006-01-11 05:46:05 PST
i haven't been able to reproduce this error on win32 with iis or apache.

> What I did is: *edit the file Config.pm
> *edit the variable libpath from "." to your bugzilla-installation path (e.g.
> "C:/bugzilla".

weird... if the paths were incorrect, and the same path is being used to create temp file and as the target, you'd expect either both to fail, or both to work.

i'd also expect a different error message -- "no such file or directory" instead of "permission denied".


maybe Safe is putting an exclusive lock on the file so other processes/threads can't access it.  perl would see this as a permissions failure.

Comment 28 Matthias Buchebner 2006-01-24 02:53:53 PST
Hi!
I guess I found the error, sorry for posting so late: It seems like the file can't  be overwritten until the old filehandle is closed.
so, just put this before the rename-command:

close $fh;

hth,
Matthias
Comment 29 Byron Jones ‹:glob› 2006-01-24 05:40:31 PST
> I guess I found the error, sorry for posting so late: It seems like the file
> can't  be overwritten until the old filehandle is closed.
> so, just put this before the rename-command:
> close $fh;

globals.pl already closes $fh before the rename (added by bug 197153 when we switched to File::Temp::tempfile).

looks like mike has either a very old globals.pl, or the close was accidently removed as part of a local modification.

--> worksforme
Comment 30 Max Kanat-Alexander 2006-05-02 11:19:35 PDT
*** Bug 336146 has been marked as a duplicate of this bug. ***
Comment 31 Nguyen Huu Thuc 2008-05-06 06:29:34 PDT
I have got this issue. I saw there are many file params.xxx in the data folder
After i deleted file params and renamed the newest params.xxx to param, Bugzilla works well.

I think it is not a good solution but at less your system can work known. 

Regards,
Thuc
Comment 32 Sadiq 2015-11-18 21:25:26 PST
I have Installed Bugzilla 5.0.1 on Windows 2008 R2 ,Strawberry Perl (64-bit) 5.22.0.1 and IIS 7.5.

I am getting this Error

Error:
write_file './data/params.json.5128' - rename: Permission denied at Bugzilla/Config.pm line 287.
For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.

[Thu Nov 19 09:52:38 2015] editparams.cgi: write_file './data/params.json.5128' - rename: Permission denied at Bugzilla/Config.pm line 287.

Steps to Reproduce:
1. goto editparams.cgi
2. Change any parameter(s)
3. save changes


These same steps were working fine with Bugzilla 4.4.1 but not with 5.0.1. Permissions are correct assigned on the folder

Regards,
Sadiq

Note You need to log in before you can comment on or make changes to this bug.