"copy" from File::Copy fails but returns success

10-16-2007

The CGI program, running under Apache, supports download of a file from
a Linux server running Perl 5.8.6. The files are stored compressed, so
the download program first copies the compressed file to a temporary
directory, then uncompresses it and handles the HTTP for the download.
My problem is that the use of "copy" from File::Copy appears to succeed
(with a TRUE return code) but then when I go to uncompress the file it's
not there.

Because of the CGI environment it's hard to give a fully-runnable
fragment, but here's the core of it.

$rc = copy ("/home/nfb/temp.txt", "/tmp/nfb");
my $output = "Return code:$rc " . `ls -l /tmp/nfb`;
print "Content-type:
text/html\n\n<html><body>$output</body></html>\n";
exit 0;

The source file exists and is chmod 777. The result from the code above is

Return code:1
-rw-r--r-- 1 apache apache 5 Oct 16 09:34 /tmp/nfb

.... which shows that the copy succeeded (return code 1) but the file is
nevertheless not in the target directory /tmp/nfb. I'm baffled.

Any ideas? If you think it's a Linux or Apache configuration problem
then please say so and I'll take this to the relevant group; but this
code worked a few weeks ago and I've not touched the Apache
configuration since.

--

Henry Law Manchester, England

10-16-2007

On 2007-10-16, Henry Law <> wrote:
> The CGI program, running under Apache, supports download of a file from
> a Linux server running Perl 5.8.6. The files are stored compressed, so
> the download program first copies the compressed file to a temporary
> directory, then uncompresses it and handles the HTTP for the download.
> My problem is that the use of "copy" from File::Copy appears to succeed
> (with a TRUE return code) but then when I go to uncompress the file it's
> not there.

Are you sure it's not a 0 return code that indicates success?
What is in $! afterward?

http://thinkexist.com/quotation/one_...an/165395.html

--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/

10-16-2007

all mail refused wrote:
> On 2007-10-16, Henry Law <> wrote:
>
>>The CGI program, running under Apache, supports download of a file from
>>a Linux server running Perl 5.8.6. The files are stored compressed, so
>>the download program first copies the compressed file to a temporary
>>directory, then uncompresses it and handles the HTTP for the download.
>>My problem is that the use of "copy" from File::Copy appears to succeed
>>(with a TRUE return code) but then when I go to uncompress the file it's
>>not there.
>
>
> Are you sure it's not a 0 return code that indicates success?

From man File::Copy:

RETURN
All functions return 1 on success, 0 on failure. $! will
be set if an error was encountered.

--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html

10-16-2007

Henry Law wrote:
> The CGI program, running under Apache, supports download of a file from
> a Linux server running Perl 5.8.6. The files are stored compressed, so
> the download program first copies the compressed file to a temporary
> directory, then uncompresses it and handles the HTTP for the download.
> My problem is that the use of "copy" from File::Copy appears to succeed
> (with a TRUE return code) but then when I go to uncompress the file it's
> not there.
>
> Because of the CGI environment it's hard to give a fully-runnable
> fragment, but here's the core of it.
>
> $rc = copy ("/home/nfb/temp.txt", "/tmp/nfb");
> my $output = "Return code:$rc " . `ls -l /tmp/nfb`;
> print "Content-type:
> text/html\n\n<html><body>$output</body></html>\n";
> exit 0;
>
> The source file exists and is chmod 777. The result from the code above is
>
> Return code:1
> -rw-r--r-- 1 apache apache 5 Oct 16 09:34 /tmp/nfb
>
> ... which shows that the copy succeeded (return code 1) but the file is
> nevertheless not in the target directory /tmp/nfb.

Obviously, /tmp/nfb isn't a directory.

> Any ideas? If you think it's a Linux or Apache configuration problem
> then please say so and I'll take this to the relevant group; but this
> code worked a few weeks ago and I've not touched the Apache
> configuration since.

That's what they always say

--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html

10-16-2007

Henry Law wrote:

> The CGI program, running under Apache, supports download of a file from
> a Linux server running Perl 5.8.6. The files are stored compressed, so
> the download program first copies the compressed file to a temporary
> directory, then uncompresses it and handles the HTTP for the download.
> My problem is that the use of "copy" from File::Copy appears to succeed
> (with a TRUE return code) but then when I go to uncompress the file it's
> not there.
>
> Because of the CGI environment it's hard to give a fully-runnable
> fragment, but here's the core of it.
>
> $rc = copy ("/home/nfb/temp.txt", "/tmp/nfb");
> my $output = "Return code:$rc " . `ls -l /tmp/nfb`;
> print "Content-type:
> text/html\n\n<html><body>$output</body></html>\n";
> exit 0;
>
> The source file exists and is chmod 777. The result from the code above
> is
>
> Return code:1
> -rw-r--r-- 1 apache apache 5 Oct 16 09:34 /tmp/nfb
>
> ... which shows that the copy succeeded (return code 1) but the file is
> nevertheless not in the target directory /tmp/nfb. I'm baffled.

The file *is* /tmp/nfb

--
Brian Wakem

10-16-2007

On Oct 16, 4:43 am, Henry Law <n...@lawshouse.org> wrote:

> My problem is that the use of "copy" from File::Copy appears to
> succeed (with a TRUE return code) but then when I go to
> uncompress the file it's not there.
>
> Because of the CGI environment it's hard to give a fully-runnable
> fragment, but here's the core of it.
>
> $rc = copy ("/home/nfb/temp.txt", "/tmp/nfb");
> my $output = "Return code:$rc " . `ls -l /tmp/nfb`;
> print "Content-type:
> text/html\n\n<html><body>$output</body></html>\n";
> exit 0;
>
> The source file exists and is chmod 777. The result from the
> code above is
>
> Return code:1
> -rw-r--r-- 1 apache apache 5 Oct 16 09:34 /tmp/nfb
>
> ... which shows that the copy succeeded (return code 1) but the
> file is nevertheless not in the target directory /tmp/nfb. I'm
> baffled.

Look at that ls output again. See that first dash? That means that /
tmp/nfb is a file, not a directory. You copied the file /home/nfb/
temp.txt to the *file* /tmp/nfb.

If a directory named /tmp/nfb does not already exist, then you need to
create it first:
unless (-e "/tmp/nfb") {
mkdir "/tmp/nfb" or die $!;
}

(Yes, yes, this is a race condition, and that's potentially bad. Only
you know the internals of your system to know whether or not it's
worth caring about - is /tmp/nfb something that gets repeatedly
created and deleted?)

Paul Lalli

10-16-2007

Quoth Paul Lalli <>:
> On Oct 16, 4:43 am, Henry Law <n...@lawshouse.org> wrote:
>
> > My problem is that the use of "copy" from File::Copy appears to
> > succeed (with a TRUE return code) but then when I go to
> > uncompress the file it's not there.
> >
> > Because of the CGI environment it's hard to give a fully-runnable
> > fragment, but here's the core of it.
> >
> > $rc = copy ("/home/nfb/temp.txt", "/tmp/nfb");
> > my $output = "Return code:$rc " . `ls -l /tmp/nfb`;
> > print "Content-type:
> > text/html\n\n<html><body>$output</body></html>\n";
> > exit 0;
> >
> > The source file exists and is chmod 777. The result from the
> > code above is
> >
> > Return code:1
> > -rw-r--r-- 1 apache apache 5 Oct 16 09:34 /tmp/nfb
> >
> > ... which shows that the copy succeeded (return code 1) but the
> > file is nevertheless not in the target directory /tmp/nfb. I'm
> > baffled.
>
> Look at that ls output again. See that first dash? That means that /
> tmp/nfb is a file, not a directory. You copied the file /home/nfb/
> temp.txt to the *file* /tmp/nfb.
>
> If a directory named /tmp/nfb does not already exist, then you need to
> create it first:
> unless (-e "/tmp/nfb") {
> mkdir "/tmp/nfb" or die $!;
> }

Better would be

my $dir = '/tmp/nfb';

-e $dir and ! -d $dir and unlink $dir
or die "can't unlink $dir: $!";
-d $dir or mkdir $dir
or die "can't mkdir $dir: $!";

which has the same race condition, but is proof against old copies of
the file hanging around.

Ben

10-16-2007

Josef Moellers wrote:

> Obviously, /tmp/nfb isn't a directory.

Danke sehr, Josef; and thanks to Brian, Paul and Ben for the same
observation and for the useful improvements.

Do you know how many times I've looked at that "ls" output, and
_completely_ failed to see that it had no "d" at the beginning? There's
none so blind as them that thinks they know what they see.

But that's the benefit of having other people help you with your problem.

--

Henry Law Manchester, England

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Hash#select returns an array but Hash#reject returns a hash...	Srijayanth Sridhar	Ruby	19	07-02-2008 12:49 PM
help! throw SIGSEGV signal while open shared object from Tomcatserver, But success in JUnit	lei.bobby@gmail.com	C++	1	12-20-2007 12:00 PM
onetime handmade daily success report, but...	Diplom Kaufmann Hinrichs - Siegert, Knut	Computer Support	0	09-18-2007 08:51 PM
parse error in gcc but success in vc.net, call a non_template class's template member function from a template class's member function!	ken	C++	2	06-28-2005 06:57 AM
A little success but still problems	=?Utf-8?B?TTc2?=	Wireless Networking	14	01-18-2005 12:36 AM