Re: [Mingw-users] tar doesn't accept Windows-style path names with drive letters?

[David G. <DGr...@am...>]

Philip Nienhuis wrote:
>Subject: Re: [Mingw-users] tar doesn't accept Windows-style path names with drive letters?

>David Gressett wrote:
>> Philip Nienhuis wrote:
>>> Hi,
>>
>>> In the course of fixing a bug for Octave on Windows (www.octave.org) I
>>> hit the following issue:
>>
>>> The msys tar.exe executable doesn't accept Windows style file names a la
>>> 'C:\full\path\to\file.fil'
>>> or even
>>> 'C:/full/path/to/file.fil'
>>> but insists on
>>> '/c/full/path/to/file.fil'.
>>> The other archivers zip/unzip, bzip2 and gzip happily accept path names
>>> with drive letters.
>>
>>> My tar version:
>>
>>> $ tar --version
>>> tar (GNU tar) 1.23
>>> Copyright (C) 2010 Free Software Foundation, Inc.
>>
>>> Am I doing something wrong, or is this a bug?
>>
>>> Thanks,
>>
>>> Philip
>>
>> It's not a bug. Any msys utilities that understand Windows file name
>> syntax just have extra frills that give them an ability to do something that msys
>> will not ask them to do.
>>
>> You need a tar that works on the MinGW side, where ability to handle Windows
>> filename syntax is needed and used, and there is in fact such a creature, which
>> can be easily installed with the MinGW installer. Start it and look for
>>
>> mingw32-bsdtar
>>
>> in the Packages column. Make sure that you have "All Packages" highlighted in
>> the package category box at the left side of the installer.

>Thanks, tried it and yes it works.

>BUT:
>mingw-get didn't supply the required libz-1.dll; I had to hunt that file 
>down and d/ld + install manually from the sourceforge site.

>Anyway, funny that gzip.exe, zip.exe and bzip2.exe can handle Windows 
>file paths OOTB but that for tar one needs a not-very-appropriately 
>named substitute ("not appropriately": bsd and Windows have little 
>relation at first sight).

>Philip

I couldn't replicate the libz-1.dll failure;  I tested the bsdtar installation on a 
computer that did not have it installed, and the installer did indeed download and 
install libz-1.dll. I'm guessing that your problem may have been caused by a
some kind of communication failure with Sourceforge.