Unlink and Rename statements on an NT Server

stovertl1
stovertl1 used Ask the Experts™
on
I am unable to make Unlink and Rename statements work on an NT server.  These statements work fine on a UNIX server.  My web host is unable to help.  

I have discovered by trial and error that the default directory is the Perl program's directory on the UNIX server, but always the root directory on the NT server.

Here is my test program.  In it, the CHMOD statement works but the others fail:

#! /usr/bin/perl

print <<SECTION1;
Content-Type: text/html

<HTML>
   <BODY>
SECTION1

   if (unlink("cgi-bin/ForumData.txt")) {
      print("      <P>unlink worked.</P>\n");
   } else {
      print("      <P>unlink failed.</P>\n");
   }

   if (rename("cgi-bin/ForumData2.txt", "cgi-bin/ForumData3.txt")) {
      print("      <P>rename worked.</P>\n");
   } else {
      print("      <P>rename failed.</P>\n");
   }

   if (chmod(0777, "cgi-bin/ForumData.txt")) {
      print("      <P>chmod worked.</P>\n");
   } else {
      print("      <P>chmod failed.</P>\n");
   }

print <<SECTION2;
   </BODY>
</HTML>
SECTION2

Thanks in advance for any help:

Tom Stover
stovertl1@att.net
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2007
Commented:
I suspect you have a path/environment issue.

Remember that you can not guarantee what your working directory is.  For example, IIS has your working directory as the document root.

Displaying the reason why the unlink and rename failed, would probably point you quickly in the right direction.  I'll make a fair bet the error will be "File not found" or similar.

Use something along the lines of:

#!/usr/bin/perl
use CGI::Carp qw(carpout fatalsToBrowser);

unlink "cgi-bin/ForumData.txt" or die "Can not unlink cgi-bin/ForumData.txt $!\n";

Author

Commented:
Dear Tintin:

Thanks for your help.  I ran your program and here is the result:

Software error:
Can not unlink cgi-bin/ForumData.txt Permission denied

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.

I used a Chmod to set the permissions to 0777.  I thought that that would enable all permissions.  Can you suggest anything further for me to do?

Thanks in advance:

Tom Stover
stovertl1@att.net
Commented:
Always use absolute paths on NT/IIS (replace "cgi-bin/ForumData.txt" with something like "c:/inetpub/scripts/ForumData.txt")
Make sure that the user your scripts runs as has write access to this directory.
But you should probably store this file in another place if you can. To give a script write access to your cgi-bin directory can cause security problems (hackers).

Perl for Windows supports chmod, but only for the owner, and only for read/write access. If your file system is somtehing other than NTFS you don't have to worry about file permissions and chmod.
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

Author

Commented:
I'm not sure that I mentioned that I am running on my web host's Windows NT 5.0 system (Windows 2000).  I have found that I can creat a file with Perl in the root directory (not cgi-bin), change its permissions to 0777 with chmod, but am then unable to delete the file with an Unlink statement, due to a permissions error.  I can, however, delete the file with CuteFTP.  I have also tried omitting the Chmod step, but I still cannot delete the file with an Unlink statement.

It is strange that I have permission to delete the file with CuteFTP, but not with a Perl Unlink statement.  Can someone explain why that might be true?

Tom Stover
stovertl1@att.net
rj2

Commented:
Probably because your script run as a user with limited permissions. Your script could send username/password of a user with more permissions to avoid this.

Author

Commented:
I don't fully understand the comment from rj2 above.  How can I tell which user my script is running as and which permissions are enabled for that user?  I would assume that I am the user and I have enabled all permissions in the IIS properties of my account. Also, how can I make my script send a particular username/password?

Tom Stover
stovertl1@att.net
Top Expert 2007

Commented:
Remember that the permissions that the webserver runs as and your own login are different, therefore it is quite understandable that you are able to delete files when the webserver process can't.

Author

Commented:
Mr. Tintin or Others:

OK, then how can I change the permissions that the webserver runs to allow me to delete a file?  Can I do it myself or does the webmaster of my web host have to do it for me?  I get the impression that the webmaster doesn't know how?

Tom Stover
stovertl1@att.net
rj2

Commented:
If you got some kind of shell access (ssh) or remote control of the web server you can do it yourself, but if the Win2K webserver is hosted by a commercial ISP and you are a regular user you probably don't, so most likely the webmaster will have to do this for you by granting "Full Control" to "Everyone" on the directory you want to have write access to. If the webmaster don't want to do that you're out of luck, you will have then have to switch ISP to make this work.
Top Expert 2007

Commented:
I deal with a lot of users that have their websites on Windows servers.  To get appropriate permissions granted, they have to put a request in to their provider/administrator to do it for them.

If your webmaster doesn't know how to do that, then you're in trouble.

Author

Commented:
The webmaster for my web host, 8ToInfinity, claims that he has now set "Full Control for Everyone", but doing so did not fix the problem.  I'm wondering if he could have done something wrong when installing his Perl system, though all other features of Perl seem to work properly.  Here is the test program I am running:

#! /usr/bin/perl
use CGI::Carp qw(carpout fatalsToBrowser);

unlink("Data/UnlinkTestFile.txt") || die "Cannot unlink Data/UnlinkTestFile.txt: $!\n";

and here is its output:

Software error:
Cannot unlink Data/UnlinkTestFile.txt: Permission denied

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.

Tom Stover
stovertl1@att.net
Top Expert 2007

Commented:
I see that your test script is still using relative paths.  You really can't guarantee what your current directory is unless you either chdir or use absolute paths, eg:

unlink("C:/somepath/Data/UnlinkTestFile.txt") or die "Can not unlink file $!\";

What is the result of:

die "file does not exist\n" unless (-f "Data/UnlinkTestFile.txt");

Author

Commented:
Mr. Tintin:

     Thanks so much for your help so far.

     I have not used an absolute path because I cannot find one that works.  I have tried:

"www.crnnetwork4.com/Data/UnlinkTestFile.txt"  -  this type of absolute path works on the Unix server, but not on the NT server.

"crnnetwork4.com/crnnetwork4.com/www/Data/UnlinkTestFile.txt"  -  This is the path that CuteFTP shows.  My seb host claims that crnnetwork4.com appears twice in the path for security reasons.

"c:/crnnetwork4.com/crnnetwork4.com/www/Data/UnlinkTestFile.txt"  -  Adding the drive letter doesn't help.

       I tried your new die statement, but nothing printed at all.  However, I tried testing on file existence and the test indicated that the file indeed exists.  I have also noticed that if I purposely use an incorrect file name, I receive a different error indicating that the file does not exist, rather than "Permission denied."

Please look over my new test program below.  Notice that I create the file from within the program and the creation definitely works (I checked with CuteFTP.)  The chmod is probably unnecessary, but I included it anyway just in case.  The test on (-f "Data/UnlinkTestFile.txt") indicates that the file exists.  However, the unlink is clearly not working, since the file is still there after the program runs.  If I delete the last part of your die statement, starting fromb the word unless, I receive the permission denied error.

--------------------------------------
Test Program:

#! /usr/bin/perl
use CGI::Carp qw(carpout fatalsToBrowser);

print("Content-Type: text/html\n\n");
print ("<html><body>\n");
print("<P>The file name should appear below.</P>\n");

open(fp, ">Data/UnlinkTestFile.txt") || die "Unable to open Data/UnlinkTestFile.txt for writing. $!\n";

chmod(0777, "Data/UnlinkTestFile.txt") || die "Unable to chmod Data/UnlinkTestFile.txt. $!\n";

if (-f "Data/UnlinkTestFile.txt") {
   print("Data/UnlinkTestFile.txt exists.</P>\n");
} else {
   print("Data/UnlinkTestFile.txt does not exist.</P>\n");
}

unlink("Data/UnlinkTestFile.txt") || die "file does not exist $!\n" unless (-f "Data/UnlinkTestFile.txt");

print("<P>The file name should appear above.</P>\n");
print("</body></html>\n");

---------------------------------------
Test Program Output:

The file name should appear below.

Data/UnlinkTestFile.txt exists.

The file name should appear above.
-----------------------------------------

Tom Stover
stovertl1@att.net
Top Expert 2007

Commented:
If the previous bit of code to test the existance of the file didn't fail, then you must have the correct relative path.

If you want to know for sure, what the full path is, use the following code

use Cwd;
$dir=cwd();

print "Content-type: text/plain\n\n";
print "Current directory is: $dir\n";

Author

Commented:
Mr. Tintin:

Thanks so much for the code to determine the relative path.  Execution of your code indicated that my web host had given me the wrong path.

I had to change to Content-Type for your code to text/html since, with text/plain, the IE tried to download the .pl file instead of executing it.  I'm not sure why.

However, I still receive the "Permission denied" error when I try to unlink a file, irregardless of whether I use the relative path or the full path.

I'm not sure what more we can do.  My web host's webmaster insists that he has set Full Control for Everyone.  Either he has not done so correctly or there is something wrong with they way he installed Perl.  He is not very knowledgeable regarding Perl.

Tom Stover
stovertl1@att.net
Top Expert 2007

Commented:
OK, we can now 100% say the problem is not Perl or paths, but a Windows/IIS permissions problem.

I appreciate your frustration with admins that don't have very good knowledge or skills.

Commented:
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

Split between rj2 and Tintin

Please leave any comments here within the next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

inq123
EE Cleanup Volunteer

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial