libarchive/libarchive-test — Issue #4: 5 - Can't extract .tar.gz archives with C:\ 
Author: amejia1
Created: 2012-01-20 19:22:44+00:00
State: open

What steps will reproduce the problem?
Create an archive using MKS tar or any of a multitude of other tar/gzip
utilities for Windows. Some archives are created containing the full path
of the compressed files; when extracting, libarchive tar chokes on these:

Example:
==============================================
C:\Windows\Temp> bsdtar -xvf d:\some_file.tar

x C:/agent/backup/: Failed to create dir 'C:': No such file or
directoryCan't create 'C:/agent/backup': No such file or directory
x C:/agent/backup/progress.log: Failed to create dir 'C:': No such file or
directoryCan't create 'C:/agent/backup/progress.log': No such file or
directory

... snip ...

bsdtar: Error exit delayed from previous errors.

C:\Windows\Temp>
==============================================

What is the expected output? What do you see instead?
Well.. GnuWin32 tar.exe has a conditional in the source code that looks
at the second character of the filename, and if it's ":" then skips two
characters. The fix is only compiled in sometimes, so may or may not work
depending on the build environment used, unfortunately.

I think a better solution is to just convert characters that will not
survive WinAPI. NTFS itself don't care what you throw at it, but WinAPI
does not allow fx ":".

In the interest of making stuff work as fast and effortlessly as possible,
silently converting all ":" to "_" in filenames (when extracting on
Windows) would work just fine.

(I don't have a need to force files to go into C:\ when the archive says
so, in fact I prefer tar to stay in the local filesystem. I can always go
to C:\ myself if that's what I want. Which it's not ;-))

Original link: http://code.google.com/p/libarchive/issues/detail?id=5