[Fix] Absolute paths in the ArchiveFileName

[iRebbok]

I fixed such a thing as an absolute path in the ArchiveFileName, it didn't work correctly with the OutputPath, because System.IO.Path.Combine doesn't expect an absolute path not in the first argument, as written in MSDN:

This method assumes that the first argument is an absolute path and that the following argument or arguments are relative paths. If this is not the case, and particularly if any subsequent arguments are strings input by the user, call the Join or TryJoin method instead.

But in Net Framework 4.6.1 there is no such method and I replaced it with System.IO.Path.GetFileName, so we get only the name of the file and combine it with the OutputPath.

I also added OutputPath to README.

[iRebbok]

@thoemmi Could you take a look at this? ;-;

[thoemmi]

Gosh, I regret having implemented ArchiveFileName and OutputPath as two separate parameters 🙄 My only requirement back when I wrote this CmdLet 8 years ago was to be able to compress a single directory and have a nice progress bar. That requirement stopped when I left one year later. And still I have to maintain this crap of mine.

Anyway, I'll trust in your PR and merge it. Thanks for your contribution.

[kborowinski]

@thoemmi @iRebbok I am afraid that this PR introduces breaking change in Compress-7Zip behavior. When OutputPath is not specified the full path in ArchiveFileName is ignored. Check this out:

Before PR #63 following command was creating Test.7z archive in C:\TMP folder. Now the archive is created in current path instead thus breaking all scripts relying on previous behavior.

Compress-7Zip -Path C:\TestFolder -ArchiveFileName C:\TMP\Test.7z

I tend to agree with @thoemmi that having ArchiveFileName and OutputPath as two separate parameters is unfortunate as they duplicate each other. I think that for the moment PR #63 should be reverted OR updated to avoid this breaking change, otherwise we can expect flow of issues being reported from people complaining that their scripts broke. In long run however I think it would be good to reconsider if both parameters are necessary.

@thoemmi Should I create new issue for this or you're OK with the provided info?

[thoemmi]

@kborowinski Thanks for reporting. I've unlisted yesterday's release 1.12.1 in the PowerShell Gallery.
Unfortunately, I don't have the time to take care of this issue. @iRebbok ?

[iRebbok]

I didn't think about it, I'll introduce the ability to specify any path with CmdLet ArchiveFileName in the new PR.