Quite off topic

[thomas]

After implementing export with archive generation (to build source releases) into the svn plugin, I encountered a "bug" which I've been struggling all day. Sometimes, it would fail for no obvious reason.
Now I have come to a really weird conclusion: There is no bug at all. Instead, it is as simple as this: tar under Windows (either msys or cygwin) cannot handle pathnames longer than 31 characters.

This sounds so hilarious, it can hardly be true, but it really seems to be the case.

Did anyone else experience that, too, or am I missing something?

Code

D:\desktop>tar -cf D:/Desktop/SomeFolder/a.tar a.txt
tar: Cannot execute remote shell: No such file or directory
tar: D\:/Desktop/SomeFolder/a.tar: Cannot open: Input/Output error
tar: Error is not recoverable: exiting now

D:\desktop>mv SomeFolder SoFo 

D:\desktop>tar -cf D:/Desktop/SoFo/a.tar a.txt

D:\desktop>mv SoFo Some

D:\desktop>tar -cf D:/Desktop/Some/a.tar a.txt

D:\desktop>mv Some SomeF

D:\desktop>tar -cf D:/Desktop/SomeF/a.tar a.txt
tar: Cannot execute remote shell: No such file or directory
tar: D\:/Desktop/SomeF/a.tar: Cannot open: Input/Output error
tar: Error is not recoverable: exiting now

[Profic]

Msys shell:

Code

Profic@PROFIC-NBOOK /e/work/web/SDN/recipe-nddocs/cpp
$ tar cf /e/work/web/SDN/recipe-nddocs/cpp/rtfReader.tar rtfReader

Profic@PROFIC-NBOOK /e/work/web/SDN/recipe-nddocs/cpp
$ 

cmd shell:

Code

E:\work\web\SDN\recipe-nddocs\cpp>c:\devel\msys\bin\tar cf e:\work\web\SDN\recipe-nddocs\cpp\rtfReader.tar rtfReader
/bin/tar: e\:\\work\\web\\SDN\\recipe-nddocs\\cpp\\rtfReader.tar: Cannot open: I/O error
/bin/tar: Error is not recoverable: exiting now

E:\work\web\SDN\recipe-nddocs\cpp>c:\devel\msys\bin\tar cf /e/work/web/SDN/recipe-nddocs/cpp/rtfReader.tar rtfReader

E:\work\web\SDN\recipe-nddocs\cpp>

So, yes, problem is there.

[thomas]

Thanks for the reply

So well... that kind of stinks. Considering the "normal" length of file paths in Windows, this effectively makes tar unusable, except if you agree to cd to the respective directory, create the archive there, and copy it to another destination later.

I've changed my code now so that tar writes to wxFileName::CreateTempFileName(). TemFileNames are usually 6-7 characters, so that leaves 24 characters for %TEMPDIR%  :?
After tar has finished, the file is moved to and renamed to what it should have been in the first place. Nasty hack, cannot say I like that. But oh well... it works.

[takeshimiya]

Are you using the latest tar 1.15.1 ?

http://www.gnu.org/software/tar/tar.html
http://directory.fsf.org/tar.html

[thomas]

No, the version that comes with the most recent msys, that's 1.13.25.

Will check out the 1.15.1 version for curiosity, but I assume that most people will have not much more recent versions than the one I use, so I'll have to keep the temp file hack anyway.


EDIT:
Version number hell, again... the msys one is 1.13.19. Cygwin has version 1.13.25.

[takeshimiya]

Ok, ok, a simply looking at tar --help I found the cause, tar (in Windows at least) doesn't support a directory parameter to -f. 

You must specify always FILES only with -f (--file), not DIRECTORIES.
You must specify the origin DIRECTORY with -C (--directory).

This will do the trick:

Code

D:\desktop\SomeFolder>tar -cf a.tar -C D:/desktop/SomeFolder a.txt

However, it is also bad,

The correct way is enclosing with quotes all directories and files, because the filenames/directories can contain spaces:

Code

D:\desktop\SomeFolder>tar -cf "a.tar" -C "D:/desktop/SomeFolder" "a.txt"

I think that always it's recommended to enclose with quotes the filenames/directories when passing as a parameter to any program.

That's it

[takeshimiya]

For more information, refer to the help of tar,

ie. the help says that you can do something like this:

Code

example% cd fromdir; tar cf - .| (cd todir; tar xfBp -)

http://www.computerhope.com/unix/utar.htm
http://www.gnu.org/software/tar/manual/html_mono/tar.html

[thomas]

Takeshimiya, this helped a lot, thank you
Hard to believe I've been using tar wrong ever since, lol. Funny enough, it works on Linux just the way I expected it to.

It is almost perfect now like this:
  export repo to %SYSTEMTEMP%/SomeTempFolder
  cd to desired location of archive
  tar -cf archivename.tar -C %SYSTEMTEMP%/SomeTempFolder .

The only issue that remains is that tar puts everything into a folder "." inside the tar archive which is a little unpleasing. Luckily, this does not matter much, as the archives unpack fine. Sure one could work around that, but I guess I'll leave it. None of the compression utilities that I have tried seems to have a problem with it.

[grv575]

Odd, but I guess . is a directory.

Wouldn't

tar -cf archivename.tar -C %SYSTEMTEMP%/SomeTempFolder *

work?

[thomas]

Odd, but I guess . is a directory.

Wouldn't

tar -cf archivename.tar -C %SYSTEMTEMP%/SomeTempFolder *

work?

No because * will be expanded to all files in your CWD, not to all files in the directory given with -C.

EDIT: Funnily, that was my first thought, too, but it is obviously wrong if you think about it. Unluckily, tar does no shell expansion of its own, so "*" will not work either - tar will complain "no such file: *".