Inconsistent failure to find module

[davies]

I am writing a module using TDD, and the tests are all passing. The module refers to another module, PodProc.pm, that is currently in a different directory. I point to it with the command use lib 'Z:/Data/Perl/PodExt';. Code from PodProc.pm is tested. However, I want this combination to interact with BugZilla. I am therefore writing a cgi module that, so far, manipulates the BugZilla database as I want. However, adding a use statement to the cgi module results in an error message Can't locate PodProc.pm in @INC (@INC contains: Z:/Data/Perl/PodExt F:/BugZilla F:/Perl/site/lib F:/Perl/lib).

This appears in the Apache error log while the browser shows a 500 Internal Server Error. I have checked that the capitalisation is identical (but the tests pass even if it's different) and originally used backslashes instead of slashes. The tests pass either way and I get the error from Apache either way. Checking the directory from the command prompt shows PodProc.pm in Z:\Data\Perl\PodExt - if it didn't, I would expect the tests to fail.

Searching indicates that use lib and changing @INC may behave differently, but since @INC is reported as containing the relevant directory, I haven't tried any other approach.

What should I try next, please?

Regards,

John Davies

Update: Thank you all. Yes, it was Apache, not Perl, that was the problem (no wonder I couldn't fix it - I was looking in the wrong place). While there was nothing in the Windows configuration preventing Apache seeing the network, Apache's httpd.conf had rules prohibiting it from accessing almost anything.

However, I report for future users that simply changing the rules wasn't enough. Because Apache loads itself at system boot time, before the user has logged into the network, putting the path, however well qualified, into the config file didn't cut the mustard. I'm sure there is a way, but the only way I could restart Apache completely was to restart the system.

My solution, which seems to be working fine, was to put a short cut to the network directory into one of the directories to which Apache already had access and to put this path into the config file as though it were not a short cut. Since the browser can't be launched until the user has logged on, the cgi file won't run until everything is in place. Apache can't spot the network linkage because it doesn't run the code and so doesn't complain.

[MidLifeXis]

Assumptions:

• apache is running as a service
• Z: is a remote drive / network share

Is it possible that apache does not have access to Z:? Unless Apache is running as you and not as a service, it is quite possible that Z: is not available to it.

[afoken]

Is it possible that apache does not have access to Z:?

Most likely. Services usually run as "Local System", and even if not, they run in different sessions than normal users. Since about Windows XP / Server 2003, drive letters are no longer global, but per user (or session, dunno). Microsoft recommends using UNC paths (i.e. \\server\share\some\path instead of x:\some\path), another way that still works (but who knows for how long?) is to install and use the AutoExNT tool. This tool installs as a service and runs a batch file whenever its service is started. From that batch file, one can map drive letters using net use x: \\server\share /user:foo topsecretpassword.

Alexander

[davies]

Z is a network share. I don't know about Apache (it's running according to its defaults), but I thought everything had access to everything else. I'll try to investigate further & see if it's a non-Perl issue.

Thanks & regards,

John Davies

[BrowserUk]

Does the webserver have permission to access the Z: share?