next »

[Aaron]

I'm running on a Windows 2000 server, using IE to view my site. I've recently migrated to a new service plan/domain with my web host.

I have uploaded all files in ASCII mode, and changed the permissions on the Calendarscript directory to read/write/delete for all users.

When I attempt to open calendar.pl, the page displays this message:

----
ERROR:
Database Lock file [d:\Customers\user1272089\www\cgi-bin\/calendarscript/calendars.lock] does not exist or is not writeable!
----

When I run the debug.pl script I receive a dozen or so messages like the following:

----
•The file does not exist | d:\Customers\user1272089\www\cgi-bin\/calendarscript/users.lock
----

The other messages are the same, related to other files - permissions.lock, calendars.lock, etc. All relate to .lock files, which (I think) must be generated by the server, as they don't appear to be part of the installation package.

My best guess is that the server can't generate the lock files it needs due to a permissions issue. I've experimented with the $BASE_DIR path, as well as with the path to perl, but I get the same results. My web host has been of limited assistance.

Any suggestions or ideas about how to resolve this would be most appreciated.

Thanks,

Aaron

[DanO]

** changed the permissions on the Calendarscript directory to read/write/delete for all users. **

There's no such thing, maybe read/write/execute??

BTW. That is not allowed on all server setups, check the host's CGI FAQs. If you're hosted on a Windows? server, you can not set file or directory permissions yourself, only the server administrator can.

** My best guess is that the server can't generate the lock files it needs due to a permissions issue. **

That would be my guess.

** My web host has been of limited assistance. **

Than you might want to consider looking for another?

JMO

Dan O.

------------------

[Aaron]

After extensive conversations with my web host tech support, they created 0-byte lockfiles with the proper names and placed them in the proper directories.

The scripts run properly now, and debug.pl gives no errors. I don't know whether that is the right solution or not, but it *seems* to have solved the problem...

Unless of course it creates other headaches down the road. We'll see I guess.

Aaron