Determining if a file exists (PERL)

Actually, that comment above is incorrect. The correct syntax is  (-e $path_to_file)

-f is the flag used to determine if the file is a "plain" file (versus a directory or symbolic link).

So, to find if the file "/test.txt" exists, you would use the code:

if (-e "/test.txt") {
  print "File Exists.\n";
}

That code sample you supplied is very confused, particularly with the use of the CGI module as it mixes the two interfaces.

Thanks for the repsonses so far. At least I now know what -e and -f mean!!

I've seen the -e (as in rkosai's comment) used in PERL scripts before (although I could only guess at what it meant)...but used in the context of files/paths on the *server* where the PERL script is run. My problem is in working out whether the file the user is uploading actually exists at *their end*.

Perhaps the issue for me is working out how to extract the path/filename from the existing code (see original post). I have now tried code along the lines of:

if (-e $Filename) {
  print "File Exists.\n";
}

...but the local file is not found even when it exists. Am I on the right track? (Or am I asking for the impossible?)

Perhaps the issue is in knowing how to specify that the file/path being tested is *not* on the server (if this can be done).

Regarding Tintin's comment...the code snippet I used is only a small section of the total script. I didn't write the script...I just want to correct a problem with it. If you are interested in the full script, you can obtained it from:

members.ozemail.com.au/~davidml/test/upload.zip .

Sorry if this question is a bit naive! This thing called PERL is still new to me and somewhat daunting!!

OK, what you want to achieve is possible, but certainly not desirable or reliable.  Essentially the only way you can check for a file existance on users local machine (in the web context) is to use a Javascript/ActiveX combo.  This won't work in all browsers, platforms and is generally disabled as a security risk.

One small nitpick.  The language is Perl not PERL.  From the Perl FAQ

What's the difference between "perl" and "Perl"?

     One bit.  Oh, you weren't talking ASCII? :-) Larry now uses
     "Perl" to signify the language proper and "perl" the
     implementation of it, i.e. the current interpreter.  Hence
     Tom's quip that "Nothing but perl can parse Perl."  You may
     or may not choose to follow this usage.  For example,
     parallelism means "awk and perl" and "Python and Perl" look
     OK, while "awk and Perl" and "Python and perl" do not.  But
     never write "PERL", because perl isn't really an acronym,
     apocryphal folklore and post-facto expansions
     notwithstanding.

$Filename =~ s/^\.+//;   # this is insecure !!
 $Filename =~ s#([^a-z0-9_+\.-])##ig;  # this is strong
# if you allow / you may add it in the characterclass
 $Filename =  './' . $Filename;     # just in case someone tries nasty things
if (-e $Filename) { print "exists"; }

# NOTE that my suggestion is very, very unsafe if you add something like ><|;%&$ to the characterclass

(Apologies for the sin of calling Perl "PERL" :-) )

Still struggling with this. It just seems to me that if the script can get a handle on the local file in order to copy it, there must be some way for it to work out during an attempted read that there's nothing to copy.

The part of the script which I assume does the actual copying is below. Perhaps this is where the error handling needs to be done:

undef $BytesRead;
undef $Buffer;
while ($Bytes = read($File_Handle,$Buffer,1024)) {
    $BytesRead += $Bytes;
    binmode OUTFILE;
    print OUTFILE $Buffer;
}
push(@Files_Written, "$SAVE_DIRECTORY\/$Filename");
$TOTAL_BYTES += $BytesRead;
$Confirmation{$File_Handle} = $BytesRead;
close($File_Handle);
close(OUTFILE);

Here's why I need the script to test the vaidity of the local file...if a customer attempts to upload a file, and makes a mistake in typing the file name, the script (as it stands) reports back with "File Uploaded!". The customer then goes along thinking all is right in the world, until two weeks later when they wonder why their job isn't completed yet, and they discover that the vendor never received the upload. Not good for customer relations!

Hence my desire to find a fix .... or a better script!

> It just seems to me that if the script can get a handle on the local file in order to copy it,

The script doesn't get a handle on the local file. The _browser_ gets the file, encodes it in the HTTP request and sends it to the web server. The CGI script reads it from there, not from the client machine.

I think I've got a solution...

undef $BytesRead;
undef $Buffer;
$i = 0;  # Initialise a loop counter
while ($Bytes = read($File_Handle,$Buffer,1024)) {
    $BytesRead += $Bytes;
    binmode OUTFILE;
    print OUTFILE $Buffer;
    $i += 1;  # increment counter
}
# Here's the new bit....
if (($Bytes == 0) && ($i == 0)) {
 # if Nothing read AND first iteration
    print $query->redirect($ERROR_BADFILE);
    close($File_Handle);
    close(OUTFILE);
    exit;
}

Testing has shown that this throws up the error page if the local filename is invalid, but succeeds if the filename is correct. Not particularly graceful, but it works!!

In your description you mention the user typing the file name into the form.  I believe this is the root of the problem.

It's not a Perl problem at al, but an html form problem  Instead of having the user type the file and path into the form, use the <input type="form"> form element.

<form><input type="file" name="upfile"></form>

This places a text box and an associated "Browse..." button in your form.  Upon clicking "Browse...", the windows browser dialog is opened allowing the user to browse to the desired file, thereby negating any possibility of entry error.  You could even add some javascript to specifically stop the user from typing an entry in and forcing them to use Browse...

Thanks. I am aware of this strategy...in fact I am using the type="file" form object for the page in question. The problem was that *without* using javascript to prevent user changing the field, there is always a risk of a bogus file name. And I didn't want to rely heavily on javascript (due to reliability issues). So I was wanting a solution that checked the file name at the back end...just in case. The code I've come up with seems to be working quite well.