File::UStore a UUID based File Storage Abstractor, Why would a temp folder not be writable???
Its been a few months since I released the File::UStore module to cpan and it has gradually attained stability over time. Not that there were a lot of bugs to begin with. Most of the bugs were in the tests rather than the code. Given the inherent complexity of writing a test for File Manipulation module for multiple platforms, I almost expected this. CPAN Testers are particularly thorough w.r.t the number of platforms their automated installer tests for a module. and it gives a nice chart of how your module fared in all those placesKudos to them for that! here is a link for th results of File::UStore http://www.cpantesters.org/author/S/SHANTANU.html#File-UStore.
In fact there are still some tests that File::UStore fails at CPAN Testers, Primary reason being that some 2-3 of the platforms(some Solaris and fedora distros) that the module is tested on did not have their temp folders writable. I am using one of the CPAN Modules for getting a temp folder for the tests and as it turns out that folder is un-writable for some platforms. Now I am not sure why a platform would do that. If it is a temp folder it should be generally writable isn't it?
Anyway the module itself works and I am fairly confident with it. If the tests fail on your platform you can simply use the force option to install it and try it out.
About the Module :
This module was born out of a need for a File storage abstracter that doesn't automatically dedup files like the usual hash based Storage modules do. Due to the nature of File Hashing, Hashed Storage doesn't allow duplicates. If the same file is stored a second time using Hashed Storage it transparently returns the same hash it had returned last time as an id without adding any new file in storage due to inherent character of hash based storage, while this is useful if a user doesn't want any duplicates occurring in a storage, this apparently trivial difference is risky in the use case where two processes upload a duplicate file to the store and both processes want to do file handling simultaneously, only one of the processes will be able to get a lock(deletion,manipulation etc.) on the file at a time and if the first process deletes the file referred to by its ID, the second process will never know what happened to the file it added.
I live in Singapore and I write about Perl, Travel and Work.
Hi Shantanu
Thanx for your post. I too get failures on Solaris which I - up to now - could never understand. Now, I'll have to check that the temp file/dir (both?) may not be writable. I agree it's strange, after all, why else would you be trying to create the file in the first place?
Cheers
I would try, for testing, to use File::Temp instead of File::Spec->temp . The test machine may not have a large /tmp directory or the user running the tester may not have the proper permissions to write anywhere except below the home directory.