Re: Phar behaviour

Steph Fox wrote: > Hi interested parties and Greg, > > I was testing earlier and came up with a bunch of anomalies around > Phar archive naming. What should be the expected behaviour for running > "php <file>" in these situations? > > 1. file.zip or file.tar when Phar is enabled > 2. file.tar.gz or file.tar.bz2 when Phar is enabled > 3. file.phar.zip (or tar) when Phar is enabled all of these should work. I have a plan to make this possible listed at the bottom of the email. > 4. file.phar.zip (or tar) when Phar is not enabled currently, this should be a parse error, but it may be useful to detect .zip/.tar and add an error message to core that questions whether this is a phar archive. > 5. file.phar.gz when Phar is enabled/disabled > 6. file.phar.bz2 when Phar is enabled/disabled ditto - this should be a parse error. > > IMHO Phar should attempt to insert a mini-stub into file.zip or > file.tar, the same way it currently does if a third-party ZIP archive > is renamed to file.phar.zip. Also IMHO, a file named file.phar.zip or > file.phar.tar should work exactly like a standard .phar AND exactly > like a standard .zip or .tar, if Phar is enabled. I'm not quite sure > what should happen there if Phar isn't installed. It may be obvious to me, but maybe it is one of my assumptions - without the phar extension, the only file format that can reasonably be expected to work is the phar file format. zip/tar files always require the phar extension in order to work. > > This brings me to the next question: What exactly is file.phar.zip? Is > it a .phar that was created as a PHAR/ZIP archive, or a .phar that was > converted to a ZIP archive, and is there supposed to be any > difference? The difference I'm seeing here - assuming the default stub > was used - is that if you run a .phar that was converted to a ZIP > archive without Phar installed you get something like: > > C:\sandbox\php5\Release_TS>php myphar.phar.zip > DÐÂ☺ Hello World ↕ index.phpnu♫ x > DÐÂ☺ ERROR: manifest length read was "320" should be > "1713645682" > > whereas the same .phar created as a PHAR/ZIP will run under PHP > regardless of whether Phar is enabled or not. (Caveat A: I don't know > whether either behaviour should be considered buggy. Caveat B: I'm > seeing a new-since-last-week bug in phar.zip creation which may be > affecting my results.) Probably the best approach is to use the default stub, and require the user to set the stub. Alternately, we could have an optional parameter for the stub $phar->convertToZip('fname', 'stub') for tar/phar: $phar->convertToTar('fname', 'stub', compression) > Last point: Since any renaming at present is wholly left to the user, > there's no way to know what a file is by just looking at it. I think > the conversion methods should actually change the name of the file > appropriately so that third-party tools (and users!) have a fighting > chance. I think this is reasonable, and the name could be an optional argument to the function to allow user overriding of default behavior. I have to run (caucuses plus concerts) but a few details to think about: 1) locating the filename of a phar should be simplified, probably to scan for the first part of the url that has a file extension, and repeating throughout the url until the actual phar file is found. 2) it may make some sense to allow creation of tar/zip files that are not executable phar archives (do not contain .phar/stub.php or .phar/alias.txt). If they are not executable, the security concern of enabling a virus would disappear, and we could use phar to make tar/zip archives with phar.readonly=1. This would be very useful for folks making on-demand archives on a website. For instance, PEAR's website could use this to make a bundle of many packages for installation all at once. 3) does it make sense to add an extract() method to Phar object? Greg