My Sellerdeck Account | Free Trial

Sellerdeck Community & Knowledge Base

Go Back   Sellerdeck Community > Knowledge Base > Online Store Issues > Checkout

Search powered by Google
Register FAQ Members List Search Today's Posts Mark Forums Read

Thread Tools Search this Thread Rating: Thread Rating: 1 votes, 5.00 average. Display Modes
Old 21-Nov-2009, 11:58 PM
KB KB is offline
Join Date: Nov 2009
Posts: 1,012
Thanks: 0
Thanked 34 Times in 29 Posts
What causes 'Error reading from OrderLock.num'?

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.
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT. The time now is 07:33 PM.

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.