|Products not being added|
|Products not being added|
Author Chris O'Connor on 01-17-2000 at 03:08 (EST)
|Having installed uStorekeeper, logged in, and set up a category, I tried to add a product. This results in an error message - 'File Error - unable to open ../cgdata/Gameboy.txt' , where cgdata is my data directory, and Gameboy is the category I have added.|
It looks like uStorekeeper should create a text file for the category that was added where products can be stored, but this isn't happening.
I've checked permissions and they all look ok.
|Messages In This Discussion|
| 1. uStoreKeeper|
Author charlie edmunds on 01-17-2000 at 18:22 (EST)
Sounds like a permissions problem. What kind of server are you on? You normally will not be able to check or changeNT permissions yourself.
Microburst Technologies, Inc.
| 3. Permissions|
Author Chris O'Connor on 01-18-2000 at 03:25 (EST)
|I'm running an NT virtual server which allows me to set up a number of domains. I can control access and set permissions on this. I've tried the directory with Write and Execute which didn't work. I've tried Read, Write & Execute which didn't work, and I've tried setting all the permissions, which also didn't work.
| 6. RE: Permissions|
Author Bill Weiner on 01-18-2000 at 06:54 (EST)
|Are you using IIS 4 to set the permissions? If so, you may need to find a different way to set the permissions. That is, below is an exert from an email from someone who was getting a similar problem with IIS. Apparently IIS 4 has a problem setting the permissions correctly, so perhaps you can use a different way to set the permissions. This person had his own server, so he was able to just use NT Explorer to do it - perhaps you (or your web hosting provider) to do the same. |
"... the short version is. I discovered on my local NT server, with IIS 4 that if you set write permission to the ./data/ directory from the IIS manager, you still got the "unable to open" error when you script, but if you set the permissions from NT Explorer it works fine."
Although, if you run the "Diagnostics" test and it says that the data directory is "OK"...then the problem may just be that you need to use the full path to your data directory instead of just the relative path. On you NT server, this may be something like "C:/users/youraccount/data" or something similar....
| 7. Permissions|
Author Chris O'Connor on 01-18-2000 at 10:28 (EST)
|>Are you using IIS 4 to set |
Yes - via a control panel that is provided by the people I host with.
>the problem may
>just be that you need to
>use the full path to your
>data directory instead of just the
>relative path. On you NT
>server, this may be something like
>"C:/users/youraccount/data" or something similar....
I've put in the full path, including the drive letter, and finally it works ! It might be worth you guys sticking something in a FAQ about the NT / IIS permissions problem. It could save people a lot of time and hassle. Thank you for your help.
| 2. RE: Products not being added|
Author Bill Weiner on 01-17-2000 at 21:48 (EST)
|There are a couple things that could be causing that problem. Here are a couple suggestions:|
1) Check that your $data_directory path is correct. From the 'unable to open ../cgdata/Gameboy.txt' error that you described, I'm guessing you set the $data_directory to "../cgdata/". Correct? If so, then your "cgdata" directory would have to be on the same directory level as your cgi-bin, something like:
You may actually want your "cgdata" directory to be a subdirectory of your cgi-bin instead. So set the $data_directory parameter to "./cgdata/" instead. This would work with the directory structure:
2) Take a look in your "cgdata" directory and see if the "Gameboy.txt" file was actually created. This will help verify that the directory exists and that it has at least write permissions.
3) Try using uStorekeeper's Diagnostic Utility (button on control panel). Under the DIAGNOSTICS TEST portion, see if the Data Directory test indicated "OK".
| 4. data directory|
Author Chris O'Connor on 01-18-2000 at 03:34 (EST)
|1. Because I'm running a virtual server and have a number of domains on it I don't want to have 1 directory under cgi-bin for data (I may purchase additional licenses for some of the other domains if I decide to sell from them and will need separate data directories for each site). I did try having the cgdata directory under the cgi-bin directory, but I had the same 'file error' message.|
2. The directory is currently set to read,write, execute. The file gameboy.txt is NOT being created in the cgdata directory.
3. I've run the diagnostic utility and it tells me that the data directory is OK, as are the others.
| 5. RE: data directory|
Author Bill Weiner on 01-18-2000 at 06:41 (EST)
|Ok, that information helps. Here are a couple more things to check/try:|
1) Instead of using the relative path "../cgdata/" to specify the location of your $data_directory, try using the full path to your cgdata directory. This will be something like $data_directory="/www/youraccount/cgdata/" or $data_directory="/users/youraccount/cgdata/" ... check with your web hosting provider on how to specify the full path to your directory if necessary.
2) Also, what type of server do you have Unix or NT? If it is a Unix server, then doing a chmod 733 on the directory with your FTP program should work fine. However, if you have an NT server, then you may have to get your web hosting provider to give the your data directory WRITE permissions.
Of couse, since you mentioned that the Diagnostics utility does indicate that the data directory is "OK", the the categories are being written somewhere.....maybe just not the place you're expecting. So really look into option #1 above.
3) One last thing to check (and again this may be related to #1 above) look in your data directory and see if the following files were created:
ustorekeeper-settings.txt - this file should have been created after the first time you configured the "General settings".
ustorekeeper-categories.txt - this file should have been created after you created the first category.
Perhaps these files are being written elsewhere on your server. Again, check #1 above.