Closed Bug 322304 Opened 19 years ago Closed 19 years ago

editparams.cgi won't save updates

Categories

(Bugzilla :: Administration, task)

Product:
Bugzilla
Component:
Administration
Platform:
x86
Windows XP
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: spiked3, Unassigned)

References

Details

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
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.
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.

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'
(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?
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.
(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.
(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?
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.
Which version of IIS?
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.
> 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.

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 :)
> 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?

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)
Active Perl rename uses MoveFileEx() API, not Rename - so you're right, in perl the rename should work.
Is this really IIS only? It seems to be a perl thing from what I gather, so it can happen with Apache, too, right?
Flags: blocking2.22?
Whiteboard: [Good Intro Bug]
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.
Summary: editparams.cgi won't save updates IIS instalation → editparams.cgi won't save updates
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.
(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"?
Flags: blocking2.22?
Fwiw, there is a posting on support-bugzilla@ which looks similar to me -- it's about a versioncache temp file not getting renamed correctly.
Whiteboard: [Good Intro Bug]
(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 ?


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.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(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
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

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.

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.


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
> 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
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
*** Bug 336146 has been marked as a duplicate of this bug. ***
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
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
I am using Bugzilla 5.0.3
I got the same error as above "Config.pm line 287"
We didn't have this before upgrade = on Buzilla 4.4.1
(In reply to ifjwogh-bugzilla from comment #33)
> I am using Bugzilla 5.0.3
> I got the same error as above "Config.pm line 287"
> We didn't have this before upgrade = on Buzilla 4.4.1

This error is a permissions error, you need to do the following:

1) ensure the localconfig has the correct value for $webservergroup, it must be the same as the group that the webserver is running under.
2) make sure you are in that group
3) re-run checksetup.pl

For further support on this issue, you might try the IRC channel. I'm leaving this open as a bug because we
*could* provide a better error message under this condition.

https://landfill.bugzilla.org/irc/
You need to log in before you can comment on or make changes to this bug.