Re: spreadsheet_excel_writer -- problem using fseek.
| From: | Andrés Felipe Hernández | Date: | Thu, 09 Oct 2003 20:39:41 +0000 |
| Subject: | Re: spreadsheet_excel_writer -- problem using fseek. | ||
| References: | 1 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-8369@lists.php.net to get a copy of this message | ||
On October 09, 2003 10:28 AM, Stefan Neufeind wrote:
> On 8 Oct 2003 at 16:51, Andrés Felipe Hernández wrote:
>
> > Hi Stefan, thanks for answering.
> >
> > Finally i found the problem. The OLE package --which is required by
> > Spreadsheet_Excel_Writer-- uses tempnam() to create some temporary
> > files.
> >
> > From the PHP manual:
> > string tempnam ( string dir, string prefix)
> >
> >
> > Creates a file with a unique filename in the specified directory. If
> > the directory does not exist, tempnam() may generate a file in the
> > system's temporary directory, and return the name of that.
> >
> > Since this function was called without using a directory path, php
> > atempts to create the file at the systems default temp directory. As
> > I am in a shared host, there was an error due to php's safemode. I
> > hacked the code and called tempname() using a directory created by my
> > own... and it worked!
> >
> > This was kind of difficult to find as I got the error after removing
> > an '@' before a function call to fopen.
> >
> > I am pretty sure very few people will run through the same problem but
> > I wanted to post this behaivior in case someone cares.
>
> Usual questions that's been mentioned several times on the list:
> - Could @ be avoided here?
> - Could a switch be added to be able to specify a temp-dir?
> - How could we improve that package?
>
> Now that you've digged through it, maybe you could come up with a
> suggestion and mail the maintainer? It's been mentioned several times
> that @ should where possible be avoided in packages in favor of real
> error-handling.
>
> Stefan
>
> PS: But you should also notify your hoster to change his temp-dir-
> setting to something appropriate.
>
>[...]
Well, I'll mail the maintainer as soon as I can and see what he thinks. As
for
the @ issue it is kind of hard to com up with a suggestion but I agree that
it should be avoided where ever it is possible.
Anyway, I think every package that makes use of this kind of default paths
should offer the possibility to overwrite them.
Finally, thanks for your help.
Andrés
PS. Yes, I defenetily need to notify the hoster :)