{"thread":{"id":"12931","subject":"git-archive loses path info when opened with Winzip?","startedAt":"2008-03-31T11:59:17Z","lastAt":"2008-03-31T20:09:13Z","messageCount":3,"participants":["Rogan Dawes","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73434","messageId":"47F0D215.1060700@dawes.za.net","threadId":"12931","inReplyTo":null,"subject":"git-archive loses path info when opened with Winzip?","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2008-03-31T11:59:17Z","receivedAt":"2008-03-31T11:59:17Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Hi folks,\n\nI have noticed something strange with \"git-archive\"-created tarballs. It \nseems that Winzip has trouble parsing the paths for certain files correctly.\n\nThe symptom is that Winzip shows some files as having been created at \nthe \"top level\" of the zip, without any path at all, while the rest of \nthe files are within their correct directory structure.\n\nI have attached a screenshot of a gitweb-created snapshot opened in \nWinzip 9.0 SR1 (build 6224), but it apparently happens in other (more \nrecent) versions of Winzip as well.\n\nThe tarball in question is at:\n\n\n\n(It's a 2.7MB file). And yes, it happens when git-archive is called \ndirectly, not just via gitweb.cgi.\n\nRegular GNU tar (cygwin) shows the correct path info: (for example)\n\n0 $ tar -tvzf /tmp/webscarab.tar.gz | grep AbstractTreeTableModel\n-rw-rw-r-- root/root 2311 2008-03-08 22:35 \nrogan/webscarab/webscarab.git/src/org/owasp/webscarab/util/swing/treetable/AbstractTreeTableModel.java\n0 $\n\nThe version of git on the server is:\n\n > [rdawes@lucas rdawes]$ which git\n > /home/rdawes/bin/git\n > [rdawes@lucas rdawes]$ git --version\n > git version 1.5.5.rc1.6.g5cc8f\n\nAny ideas what may be going wrong here? Note that it doesn't seem to \nhappen when generating a ZIP using git-archive, but only when generating \ntarballs.\n\nRegards,\n\nRogan\n"},{"id":"73452","messageId":"47F13FCE.1010502@lsrfire.ath.cx","threadId":"12931","inReplyTo":"47F0D215.1060700@dawes.za.net","subject":"Re: git-archive loses path info when opened with Winzip?","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2008-03-31T19:47:26Z","receivedAt":"2008-03-31T19:47:26Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Rogan Dawes schrieb:\n> Hi folks,\n> \n> I have noticed something strange with \"git-archive\"-created tarballs. It\n> seems that Winzip has trouble parsing the paths for certain files\n> correctly.\n> \n> The symptom is that Winzip shows some files as having been created at\n> the \"top level\" of the zip, without any path at all, while the rest of\n> the files are within their correct directory structure.\n> \n> I have attached a screenshot of a gitweb-created snapshot opened in\n> Winzip 9.0 SR1 (build 6224), but it apparently happens in other (more\n> recent) versions of Winzip as well.\n\nOh, well.\n\nEach file in a tar archive has at least a 512-byte header. This header\ncontains a name field, 100 bytes long. When it became clear that it\nwould be nice to support file names longer than 100 characters, another\n155 bytes in the header was designated as a prefix field (see tar.h).\n\nThe full file name is constructed by concatenating the prefix, a path\nseparator (/) and the name field -- if a prefix exists. That's how\nPOSIX defines it, anyway. Apparently WinZip ignores the prefix field.\n\n7-Zip honours the prefix field, by the way. But it doesn't understand\nPOSIX extended headers; I suspect that WinZip doesn't, too.\n\nThat probably makes the easiest way to fix this problem at git's end a\nnon-starter. Git-archive tries to:\n\n 1. fit the path in the name field (up to 100 bytes),\n 2. in the prefix and name fields (up to 255 bytes),\n 3. or if even that isn't enough it stores it in an extended header.\n\nNow we could simply make git-archive forget the second option -- but\nsince support for POSIX extended headers is even more scarce, this\nprobably won't help.\n\nThe second option is to stop encoding long paths using the POSIX method\nand start doing it e.g. the GNU way -- or some other tar dialect that is\nsupported more widely than the official one. NOTE: I haven't checked if\nWinZip understands the GNU extensions; it's possible that this problem\ncan't be solved on git's side at all!\n\nIn any case, there are better options:\n\n - Don't use long file names (just kidding :).\n - Use a tar extractor that understands the prefix field, e.g. 7-Zip.\n - Use zip (but beware of its 65535 bytes name length limit! ;).\n - File a bug report with WinZip.\n\nRené\n"},{"id":"73453","messageId":"47F144E9.2040709@dawes.za.net","threadId":"12931","inReplyTo":"47F13FCE.1010502@lsrfire.ath.cx","subject":"Re: git-archive loses path info when opened with Winzip?","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2008-03-31T20:09:13Z","receivedAt":"2008-03-31T20:09:13Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"René Scharfe wrote:\n> Rogan Dawes schrieb:\n>> Hi folks,\n>>\n>> I have noticed something strange with \"git-archive\"-created tarballs. It\n>> seems that Winzip has trouble parsing the paths for certain files\n>> correctly.\n>>\n>> The symptom is that Winzip shows some files as having been created at\n>> the \"top level\" of the zip, without any path at all, while the rest of\n>> the files are within their correct directory structure.\n>>\n>> I have attached a screenshot of a gitweb-created snapshot opened in\n>> Winzip 9.0 SR1 (build 6224), but it apparently happens in other (more\n>> recent) versions of Winzip as well.\n> \n> Oh, well.\n> \n> Each file in a tar archive has at least a 512-byte header. This header\n> contains a name field, 100 bytes long. When it became clear that it\n> would be nice to support file names longer than 100 characters, another\n> 155 bytes in the header was designated as a prefix field (see tar.h).\n\n[snip]\n> In any case, there are better options:\n> \n> - Don't use long file names (just kidding :).\n> - Use a tar extractor that understands the prefix field, e.g. 7-Zip.\n> - Use zip (but beware of its 65535 bytes name length limit! ;).\n> - File a bug report with WinZip.\n> \n> René\n> \n\nHi René,\n\nThanks for the detailed explanation. I guess I should file a bug report \nwith WinZip, although that won't solve the problem for most of the \npopulation.\n\nMy best bet seems to be to provide the option to create Zip files rather \nthan tarballs (i.e. upgrade my gitweb.cgi to something more recent).\n\nRegards,\n\nRogan\n"}]}