by Will Bontrager
Copyright 2004 Bontrager Connection, LLC
Some servers present special difficulties when restoring file backups in directories created with scripts.
This article provides a useful solution for handling these situations.
The server I’m talking about will let scripts create directories and files, but it won’t let the created directory’s permissions be changed with an FTP program and it won’t let the files it creates be deleted or overwritten with an FTP program.
Why should you care?
Because if you need to restore backup files, you won’t be able to do it with FTP &151; unless you do it using the method I describe in this article. You want to learn how to do it now, not scrambling to google in panic when you can’t restore backup files.
Testing Your Server
To test your server to see if yours is one of the ones I’m talking about, simply install the following script and run it.
To install, upload it with an FTP program as a plain text file and give it 755 permissions.
#!/usr/bin/perl use strict; mkdir "testdirectory",0777; open W,'>testdirectory/testfile'; print W 'testing'; print "Content-type: text/html\n\n<html><body>Done."; # end of script
After you’ve run the script, see if you can change the permissions of the test directory “testdirectory” that it created. And see if you can delete the “testfile” file created in the test directory.
If you can change the test directory permissions and delete the test file, you don’t have one of the servers addressed here. And you won’t need this article, at least for now.
If you can’t, then you do have one of those servers.
Note: If the script didn’t create the test directory at all (refresh the directory listing in your FTP program window to make sure), then do this:
- Create a subdirectory in your cgi-bin.
- Give the subdirectory 777 permissions.
- Install the test script in that subdirectory.
- Run the script.
- Test the directory permissions and the ability to delete the test file.
If you discover that you have one of those servers, you can use the script below to delete the test file and test directory:
#!/usr/bin/perl use strict; unlink 'testdirectory/testfile'; rmdir 'testdirectory'; print "Content-type: text/html\n\n<html><body>Done."; # end of script
The Explanation
(You don’t have to read the next 4 paragraphs in order to understand the article. Read it if you’re curious. But if your head spins, simply skip down to the “How To Do It” section.)
On Unix/Linux servers, when an FTP program logs in, it is running with a User ID and a Group ID. The User ID might be the same as the username used to log in. The Group ID might be “accounts” or “web” or whatever the hosting company has assigned when it configured the server.
When a script runs on that server, it has a User ID and a Group ID, too. Those IDs might be the same as the FTP IDs or they might not. For example, the User ID might be “www” and the Group ID “other” or “everybody” or whatever the hosting company configured it for.
On the servers this article addresses, the User ID and the Group ID are different for FTP than they are for scripts running on the server. (Some FTP program display the User and Group ID’s when they display a listing or directory information.)
Because the scripts are running with different ID’s, the directory and file permissions don’t allow the FTP program to change things. The FTP program is treated like a child that can look in the store window but can’t touch the goods.
How To Do It
If you can’t use FTP to restore files directly, then have a script do it for you.
FTP can be used to upload the script and the file to be restored, both in a directory in the cgi-bin. The script, because it will be running with the correct ID’s, can then copy the file to where it needs to be.
Here is such a script (about 25 lines):
#!/usr/bin/perl
use strict;
print "Content-type: text/html\n\n<html><body>";
# The location/name of the file to read:
my $FileToRead = 'myfile.db';
# The location/name of the file to write:
my $FileToWrite = 'database/myfile.db';
if(open R,"<$FileToRead")
{
binmode R;
if(open W,">$FileToWrite")
{
binmode W;
print W <R>;
close W;
close R;
}
else { print "Can't create $FileToWrite: $!<br>"; }
}
else { print "Can't open $FileToRead: $!<br>"; }
print 'Done.';
# end of script
Before you upload the script, edit it in two places:
- Between the single quotation marks following $FileToRead, type the file name of the file that will be used for the restoration.
- Between the single quotation marks following $FileToWrite, type the file name that will be restored.
In both instances, if the file named in the edit is not located in the same diretory where the script will be installed, type the directory location with the filename.
The $FileToRead file needs to be uploaded with the script, or somewhere that the script can find it.
When the script runs, it creates a $FileToWrite with a copy of $FileToRead. (If $FileToWrite already exists, it is overwritten.)
You’ll need to follow that procedure for each file you wish to restore.
It’s a work-around, and a little work, but it can be done when needed. You’re not stuck without a way to restore data files.
Will Bontrager
Provided by
WillMaster Possibilities
(Powered by Master Syndicator.)
The post Restoring Files When FTP Can’t appeared first on Open Source.