Unable to create file on windows

[pwhelan]

Stash v0.10.1 on windows fails with the following error.

Message: touch() [function.touch]: Unable to create file C:\wamp\www\clickfortime.com\httpdocs/application//cache/1952a01898073d1e/561b9b4f2e42cbd7/a8b72798beb911ae/98c8c8907d45950a/b2eb734903575495/3b57a32e2841bda5/dc960c46c38bd16e/953d97cdeefdbc68/e9772a20f09b5d13/28a579892c11a4c8/cfcd208495d565ef/66e7dff9f98764da.php because Invalid argument

My best guess is because it is not using the correct path directory separator.

[tedivm]

Can you run the test suite and let me know what comes back? Unfortunately I don't have a windows box handy at the moment.

[pwhelan]

This is the output when my coworker ran it on their machine:

Fatal error: Interface 'Stash\Driver\DriverInterface' not found in C:\wamp\www\site\httpdocs\application\third_party\Stash\tests\Stash\Test\Exception\ExceptionTest.php on line 27

Call Stack:
    0.0004     329128   1. {main}() C:\wamp\bin\php\php5.3.8\phpunit:0
    0.0111    1278200   2. PHPUnit_TextUI_Command::main() C:\wamp\bin\php\php5.3.8\phpunit:46
    0.0111    1278616   3. PHPUnit_TextUI_Command->run() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\TextUI\Command.php:129
    0.0142    1637280   4. PHPUnit_Runner_BaseTestRunner->getTest() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\TextUI\Command.php:150
    0.0581    1921592   5. PHPUnit_Framework_TestSuite->addTestFiles() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\Runner\BaseTestRunner.php:96
    0.2022    4778448   6. PHPUnit_Framework_TestSuite->addTestFile() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\Framework\TestSuite.php:416
    0.2026    4778680   7. PHPUnit_Util_Fileloader::checkAndLoad() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\Framework\TestSuite.php:355
    0.2036    4778840   8. PHPUnit_Util_Fileloader::load() C:\wamp\bin\php\php5.3.8\pear\PHPUnit\Util\Fileloader.php:76
    0.2044    4797000   9. include_once('C:\wamp\www\site\httpdocs\application\third_party\Stash\tests\Stash\Test\Exception\ExceptionTest.php') C:\wamp\bin\php\php5.3.8\pear\PHPUnit\Util\Fileloader.php:92

I am sure though this is another problem. This is with the v0.10.1 branch.

[pwhelan]

I was able to identify the problem; there was an error creating the directories in the FileSystem driver when the name exceeded the file path limit for windows. I was able to resolve it for myself by switching the hash function for Stash\Utilities::normalizeKeys to crc32. With this the names are short enough to work. Note: CRC32 should be good enough unless someone tries to deliberately subvert it.

[pwhelan]

Would it be an acceptable fix to default the hash function to CRC32 on win32? Either that or I was going to make it configurable. I will only be using it on windows for testing so it should be fine.

[tedivm]

Configurable works far better. CRC is not designed to be a hashing function, it's an error checking function, so unlike md5 (or any hash function) it wasn't designed to avoid collisions. While I haven't done any testing myself, I would be concerned about errors from key collisions.

[pwhelan]

CRC is not designed to be a hashing function, it's an error checking function, so unlike md5 (or any hash function) it wasn't designed to avoid collisions.

I personally would not use for anything beyond simple testing or development. Off the top of my head I cannot think of another algorithm that is shorter than md5 but which should give some minor assurances against collisions.

[gggeek]

see http://stackoverflow.com/questions/4567089/hash-function-that-produces-short-hashes for ideas...
Or here: http://php.net/manual/en/function.base-convert.php (comment by Clifford dot ct at gmail dot com)

[tedivm]

I'm going to close this issue out now, as the PR was accepted and seems to resolve this.

[gggeek]

mmm, pull request was merged, but no alternative to md5 was provided/recommended/mentioned, right?
Also the test code in the pull request could probably do with more than 4 key elements...

[tedivm]

You could do a PR on more code coverage (I'd really appreciate it, in fact). If not I'll take a look at expanding it myself.

I'm planning on issuing updated documentation (hosted at http://stash.tedivm.com) and will include that comment. I've made an issue over there to track it ( tedivm/stash-docs#8 ).

Any other thoughts? I'm reopening the ticket to keep the conversation going.

[gggeek]

Sorry for not sending any pull request so far, I'm just overloaded (all the issues I'm opening come from a customers project I'm working on). Will do as soon as I have 30 free seconds

[pwhelan]

no alternative to md5 was provided/recommended/mentioned, right?

For the moment the code uses crc32. Probably not a safe choice for production, although it might be I have not fully tested it. It is good enough for development, which was my concern at the moment.

[tedivm]

I think this issue is resolved, but if anyone has a problem please feel free to reload it.

[asabosch]

There is a use case where this problem is not resolved: Right now we have an exception on windows systems thrown when the path is too long. But I discovered the problem on a linux system: CentOS on a vm (virtualbox / vagrant on windows host with shared drive) The vagrant synced folders are tied to windows limitations.

[gggeek]

@xgathos in my own experience, Vagrant synced folders have always been problematic: slow to use, prone to problems when dealing with symlinks, etc. I have always been much better off with storing the codebase within the VM itself and sharing it to the windows host via Samba (only downside: you need the VM to be on to access the files)