This message occurs as a result of a change on the web server. See below for details of how the problem may occur.
Fixing the problem…
This will require FTP or Shell access to the server by a user with sufficient privileges to be able to change the permissions and/or modify the *.num files. You may need to ask your ISP to assist.
Open the acatalog directory on the web server and look for the files of type *.num.
First choice solution…
Change the owner of the *.num files to the username of the process that is the effective user that runs the perl scripts. Place a test order to check that the scripts can determine the next order number.
Second choice solution…
So long as both Orderlock.num and Backup.num exist then delete OrderLock.num and set the permissions of Backup.num to 777, place a test order this will recover Order.num from Backup.num, then reset the permissions of Backup.num to 600.
How the problem occurs…
To maintain the order number sequence three files are used, they are Order.num, Backup.num and OrderLock.num. Normally you will only see Order.num and Backup.num in the acatalog folder of the server.
When a buyer places an order the system must make sure that no other buyers can get the same order number. This is achieved by: -
- renaming the Order.num file to OrderLock.num
- writing the order number in OrderLock.num
- writing the new order number to Backup.num
- renaming OrderLock.num back to Order.num thus releasing the lock.
These actions require that the effective user that runs the perl scripts must be able to read and write to the three files. To do this the effective user running the perl scripts must own the three files.
The following changes to the server will result in the effective user no longer being the owner of the files: -
- Changing the ownership of the file. One reason this might be done is if the administrator believes that the site owner should own the files.
- Changing the UserID of the effective user that runs the Perl scripts. May happen if the server administrator deletes the username and then adds the same name back without specifying the same UserID.
- Changing the user that runs the web server (e.g. Apache), Perl scripts, by default, are run as the same owner as the owner of the web server.
- Running more than one web browser on the server with different user names. If the web server runs the Perl scripts then the owner of the Perl script will vary depending on which web server processes the request.
- Changing the Perl Scripts to be run with or without a CGI Wrapper, which is a security feature for Perl Scripts. When a wrapper is used the Perl scripts are usually run as the owner of the Perl script files without the wrapper the scripts are usually run as the owner of the web server (e.g. Apache).
- When the site is re-configured to start or to stop using SSL then the effective user of the Perl scripts may be different.
Fixing the problem…
This will require FTP or Shell access to the server by a user with sufficient privileges to be able to change the permissions and/or modify the *.num files. You may need to ask your ISP to assist.
Open the acatalog directory on the web server and look for the files of type *.num.
First choice solution…
Change the owner of the *.num files to the username of the process that is the effective user that runs the perl scripts. Place a test order to check that the scripts can determine the next order number.
Second choice solution…
So long as both Orderlock.num and Backup.num exist then delete OrderLock.num and set the permissions of Backup.num to 777, place a test order this will recover Order.num from Backup.num, then reset the permissions of Backup.num to 600.
How the problem occurs…
To maintain the order number sequence three files are used, they are Order.num, Backup.num and OrderLock.num. Normally you will only see Order.num and Backup.num in the acatalog folder of the server.
When a buyer places an order the system must make sure that no other buyers can get the same order number. This is achieved by: -
- renaming the Order.num file to OrderLock.num
- writing the order number in OrderLock.num
- writing the new order number to Backup.num
- renaming OrderLock.num back to Order.num thus releasing the lock.
These actions require that the effective user that runs the perl scripts must be able to read and write to the three files. To do this the effective user running the perl scripts must own the three files.
The following changes to the server will result in the effective user no longer being the owner of the files: -
- Changing the ownership of the file. One reason this might be done is if the administrator believes that the site owner should own the files.
- Changing the UserID of the effective user that runs the Perl scripts. May happen if the server administrator deletes the username and then adds the same name back without specifying the same UserID.
- Changing the user that runs the web server (e.g. Apache), Perl scripts, by default, are run as the same owner as the owner of the web server.
- Running more than one web browser on the server with different user names. If the web server runs the Perl scripts then the owner of the Perl script will vary depending on which web server processes the request.
- Changing the Perl Scripts to be run with or without a CGI Wrapper, which is a security feature for Perl Scripts. When a wrapper is used the Perl scripts are usually run as the owner of the Perl script files without the wrapper the scripts are usually run as the owner of the web server (e.g. Apache).
- When the site is re-configured to start or to stop using SSL then the effective user of the Perl scripts may be different.