ZipArchive and Windows about spout HOT 16 CLOSED

btw i made these modifications to get this into work:

XLSX.php line 169

$filePath = str_replace('/', DIRECTORY_SEPARATOR, $this->filePath . '#' . $worksheetDataXMLFilePath);
$worksheetDataFilePath = 'zip://' . $filePath;

and so on in 2 other places where i found 'zip://' and now its working on my windows server

from spout.

@Janokapapa, can you please specify which version of Spout you are using as well as which version of Windows? It worked fine with WAMP and PHP 5.4. It may be a PHP configuration.

from spout.

PHP 5.4.11
Spout 1.0.7

I guess for windows/php/ziparchive class its better if paths defined with DIRECTORY_SEPARATOR, at least in this version of PHP its working this way

from spout.

As stated on php.net: http://php.net/manual/en/function.basename.php

On Windows, both slash (/) and backslash () are used as directory separator character. In other environments, it is the forward slash (/).

This means that on Windows, you can use "" or even mix "/" and "" and it will still work. Same goes with the ZipArchive class (confirmed by the maintainer of the library). So there has to be another reason.

Are you using WAMP or an actual Windows server?
Does it work if you only replace the "/" by "" in the zip internal path (XLSX.php line 169):

$filePath = $this->filePath . '#' . str_replace('/', DIRECTORY_SEPARATOR, $worksheetDataXMLFilePath);
$worksheetDataFilePath = 'zip://' . $filePath;

from spout.

i am using uniform server, yes it works only with "". this was the reason of starting this issue :)

from spout.

so i guess its older ZipArchive or so, actually this server i use built in 2011... but then it seems that its not backward compatibel with windows and php > 5.4.0

from spout.

i have just tried the newest uniform server built with php 5.4.40, and its still an issue

from spout.

@Janokapapa, does it work if you only replace the "/" by "" in the zip internal path (XLSX.php line 169) ?
i.e. if the final path is "path/to/xlsx/file.xlsx#xl\worksheets\sheet1.xml" ?
Or does it need to contain "" everywhere? "path\to\xlsx\file.xlsx#xl\worksheets\sheet1.xml"

from spout.

its only needed inside the archive, the outside handled well it could be mixed / or \ as usual

from spout.

ok, tested, working nicely, thanks :)

from spout.

Hey @Janokapapa, there seems to be an issue with the change that was merged to fix your problem.
While it fixed your issue, it broke the reader (see #52 (comment)).

The correct way to write a path should be using / not \. So I'm going to revert the change I made.
Now, I still want to understand why it's not working for you. Can you tell me more about your configuration?
Which OS did you use? Which version of this OS? Do you have the version of UniformServer (as well as Apache and libXML version)?

Thanks!

from spout.

hey I thought its already a past, for me after ur change was working fine on windows and linux as well. I wrote u that one of my server is a windows(7), php 5.4.40, and libxml: 2.7.8. Why not just use DIRECTORY_SEPARATOR instead of slashes?

from spout.

For some reasons (that I'm trying to understand), using a backslash within the zip file path breaks the reader. This is what is reported by #52 as well as what I reproduced using both WAMP and Uniform server (as described at #52 (comment)).

According to the spec (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT), file paths within the zip file should contain / not \ (section 4.4.17 of the spec). This is also what the maintainer of the ZipArchive library told me.

So I think your problem is the exception. The rule being to use forward slashes.
Now I still want to understand why it fails in your case...

from spout.

Regarding the Uniform Server you were using, are you talking about "Uniform Server ZeroXI"? Or did you test with another version?
Also, if the file you were using for testing does not contain anything sensitive data, would you mind sending it to me (adrien [at] box.com). Maybe the problem comes from the file itself...

from spout.

i tried with zeroxi and nano as well, and i exported/imported the file with ur class, i dont have those test files anymore, also the working version rolled into production, at the moment i cant reproduce the error with the old one

from spout.

Alright, I made some progress :) It seems like there is something wrong with the generated file itself! I was testing with an file generated on Linux before. I tried creating the file from Windows and I am not able to reproduce the issue. Thanks for your help

from spout.