Or did I misunderstand your problem?

When you request a file via <input type="file" name="f1"/>, what you get back in your parameters is browser dependent. IE7 (and IE8?) sends the full local path name. Firefox only sends back a relative local path name. So this isn't likely a CGI problem at all. Some developers feel that providing the full path name might violate your privacy and make your machine less secure. If "MyData.xml" is stored in "C:/Hotties/MyPics/MyData.xml" or "C:/HouseholdFinances/MyData.xml", you might not be terribly happy sending the absolute path to the server at your company or that new file sharing site you are trying out.

I don't do much web work, but there are various solutions posted across the internet. According to the standard for the input tag's FILE type (see RFC 1867), the browser is supposed to send the file contents to the server as the mime type "multipart/form-data". The file name is in fact optional and the only requirement in the RFC is that enough of the name should be sent so that cross linked files can be properly cross referenced. The RFC is a bit vague on what exactly that means. Apparently support for the RFC tends to vary among browsers. You can get details on support per browsers and various alternatives at http://www.cs.tut.fi/~jkorpela/forms/file.html.

One option is to skip the <input> tag altogether and use some custom client-side java script to prompt the user and send the full path. However, some users disable javascript as a matter of policy, so you'll need to check with your users if you go that route.

Hopefully, monks with more practical experience than I will post and explain what they have found worked for them.

Best, beth

Update: CGI's upload() method returns a file handle to a stream containing the file contents. Please see CGI for details (search for the phrase: To be safe, use the upload() function). If you need more, Unforgiven's link in the note above also has examples of what works and what doesn't.

When you request a file via <input type="file" name="f1"/>, what you get back in your parameters is browser dependent. IE7 (and IE8?) sends the full local path name. Firefox only sends back a relative local path name. So this isn't likely a CGI problem at all. Some developers feel that providing the full path name might violate your privacy and make your machine less secure.

Also, if the full filename is passed, your machine (or the source machine) may not have access to the directory. This is for security purposes. You are usually better served by deciding in advance where files are to be stored and setting permissions appropriately:
• Read only for source directories and files
• Write (only) for target directories (if system wide)
• Read/Write for target directories owned by the target user
This way, the client side can upload (but not download or view) files on the source. The client can download to permitted locations on the client side system. The client can do whatever they want in their own file structure.

If you're using the CGI module, this may be helpful: Upload files using CGI Module

You're actually getting the file and the filename, you just have to access the file data with the "upload" method.

The full path to the original file on the client's computer is of no use to your script running on the server. But the client sent you both the name (relative or full) and the data. Consult the docs of the module you use to extract the CGI parameters (CGI.pm, CGI::Lite, ...) how to read the data. The original file name is just a comment, a suggested name for the file once you read the data and want to store them somewhere. The data are either still in memory or more likely in a temporary file whose name most likely doesn't match that string of characters at all.