- fix metadata handling with cached phars
- fix virtual_dirs with rmdir
- ensure that after copy-on-write, all existing Phar objects link to the newly copied phar data
* found felipe's segfault in util.c and fixed the segfault (3 tests fail due to odd behavior of . and .. on this machine)
* fixed serious flaws in the setting/resetting of is_data - now it works properly. Assume
all new PharData are tar-based, and allow passing Phar::ZIP to PharData constructor to override this
* fix broken earlier commit, introduced segfault that broke 20 tests here
phar_find_in_include_path. We were allowing data-based phars to be executed, and actually marking phar-based phar archives
without '.phar' in the name as data-based phars, which would allow modifying them even if phar.readonly=0. Add test for this sinister case
@Greg: There are two (identical) recurring memleaks I can't seem to kill, both marked FIXME. Would you please take a look?
[DOC] $phar->buildFromDirectory(dirname[, regex]). Return value is an array pairing each file in the archive index with the original path on the filesystem.
this also resulted in a major fix for mounted directories, which were recycling the 'link' field which
could cause stupid conflicts with actual links, so move that to new 'tmp' field.
1 - executable phars must contain '.phar' in the filename
2 - non-executable phars must not contain '.phar' and must have an extension of at least 1 character
In addition, phar filenames must exist if opened for read, and the directory containing the phar must exist if opened for creation
if opened for creation, the file must not already exist
[DOC]
conversion is now split into 3 separate methods
1\) convertToZip\(\) convertToTar\(\) and convertToPhar\(\) exclusively change file format
2\) compress\(\) sets compression, accepting Phar::GZ, Phar::BZ2, or Phar::NONE
3\) convertToExecutable\(\) allows stub creation in tar/zip, convertToData\(\) prevents it
all methods return either Phar or PharData objects, allowing fluent interface.
only 1 test has been converted to the new format, but the API works
5.3 code expects the proposed patch for stream wrapper in include_path to be committed
5.2 code only supports phar stream wrapper in include_path.
this is a 2-step process. After this, more magic, particularly in funcinterceptors.c will be
converted to use phar_resolve_path, which is far safer than the current implementation.
this needs windows and 5.2 testing unix/windows
Note: two tests currently fail. IMHO we should be throwing E_ERROR on encountering a corrupted archive, not trying to throw a trail of exceptions...
New tests still to be written, not all functionality is in place yet.
