from http://us.php.net/manual/en/phardata.compress.php:

"By default, the extension is .tar.gz or .tar.bz2  for compressing a tar, and .tar for decompressing."

<?php

    $p = new PharData('./wes-laptop.local.test.tar');
    $p->addFile('./test.php'); 
    $p1 = $p->compress(Phar::GZ, '.local.test.tar.gz');
    $p2 = $p->compress(Phar::BZ2, '.local.test.tar.bz2');

?>

works as you desire it to work.

Thanks, please re-read my ticket, you seem to have missed my point.

I did not miss the point :).  You are thinking that ".tar" is the extension, but the extension is all things after the first period.  Otherwise, we can't do ".phar.tar.gz" as an extension or ".tar.phar.gz" or ".phar.tgz" all of which are valid and equivalent, without extreme bloat.

Your file's extension is ".local.test.tar" and as the docs say, it replaces this with the default extension ".tar.gz" and ".tar.bz2"

Well, I don't agree with your definition of file extension, but that's largely irrelevant as I'm probably wrong ;)

Thanks for the input, I'll just avoid having "periods" (as you call them) in my file names.

closed is used for bugs where a fix was made, -> Bogus

"The extension is all things after the first period" should be added to the PharData::compress description in the PHP documentation.
I wasted about 1 hour before finding your explaination. Thank you for your help, I understand how it works now.

But it's a problem to create a compress file with a name different from the original file because this name contains a dot
It would be better to keep all the name of the file (without removing a part of it) and to simply add .gz or .bz2, like the UNIX commands do and like in other languages :

test -> test.gz
test.tar -> test.tar.gz (and not test.gz)
test.123.tar -> test.123.tar.gz (and not test.gz)

If I compress in the same folder 3 files named test, test.tar and test.123.tar, I will only have one file test.tar.gz!!!

I create a file name toto.123.file1.tar with $phar->buildFromDirectory("$directory")
I create a file name toto.123.file1.tar.md5 -> no problem
How to create a compressed file named toto.123.file1.tar.gz? I must do a special script to keep 123.file1 in a variable???

I also think that this bug should be reopened.

The current API does not seem to work very well, as it makes it extremely hard to create archives with dots in their filenames

Sorry to differ with you "greg at chiaraquartet dot net". But the way Phar deals with extensions is incoherent with SPL.

CODE
--------
<?php
$test = new \SplFileInfo('/tmp/someroute/archive.tar');
echo $test->getExtension() . "\n";

$test = new \SplFileInfo('/tmp/someroute/archive.tar,gz');
echo $test->getExtension() . "\n";

RESULT
--------
tar
gz

So, it seems very clear what is a consistent extension to PHP. To add up, cli command gzip deals the situation just adding '.gz' at the end, not truncating after the first 'period'. 

From a 'tar' approach, tar create an archive of files (hence the .tar extension), and if you have specified the compress option runs a compress process at the end (hence the .gz, .bzip extensions). It's a "concatenation of formats".

But the problem here is not what we think is right or wrong, the thing is that PharData::compress() does not work as expected when the filename has dots in it. 

As a final note. Current documentation states: "In addition, this method automatically renames the archive, appending .gz, .bz2 or removing the extension if passed Phar::NONE to remove compression. Alternatively, a file extension may be specified with the second parameter.", Appending is not the same as substituting.

This bug needs to be reopen.

Even PHPs own pathinfo() does not agree with the definition of "file extension" that is used here. According to pathinfo() the extension is everything after the _last_ dot, not everything after the _fist_ dot. Pathinfos behavior is consistent with the expectation of the reporter of the bug and with the conventions of common unix tools.

It gets even worse when unpacking files. Unpacking 

wes-laptop.local.test.tar.gz

with decompress() should really produce 

wes-laptop.local.test.tar 

but it does produce 

wes-laptop.tar



Please reopen and fix this bug.

What a pity that misunderstanding what a "file extension" is (what obviously happened despite the respectful tone on the comments) and, even worst, scorning all comments, had made this method useless, since it is completely unreliable for doing its work.

Please, reopen and fix the bug.