This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: two problems with cygwin's zip

  the first problem (of seeing absolute paths in zips) occurs when using 
forward slashes as well.  it's an absolute path issue rather than a 
slash-handedness issue.  thus, this is still a bug relevant to cygwin's 
zip, even if we must discount slash issues in paths.  but i don't 
suggest that we abandon those issues...

  it seems pretty disturbing to me that a unix emulation environment 
running under ms-windows would have many problems parsing ms-dos paths. 
 i realize the intrinsic difficulties with the backslash as an escape 
character, but i also am aware that many of the tools i use at the 
office are really psyched about generating the backslash as the path 
separator.  if the cygwin tools are unable to handle those generated 
paths, then that signficantly detracts from my ability to work with 
cygwin on the ms-windows platforms.
  in most paths it's fairly obvious which interpretation is intended. 
 backslashes after colons should probably always be considered 
separators for the rest of the path.  it's probably also a reasonable 
assumption that backslashes are escape characters only when they are 
escaping something that needs it, such as a space embedded in a 
pathname.  unfortunately, that leads to consideration of the pattern 
"\*", which might be an escaped asterisk or which might be a wildcard 
appended to an ms-dos path.  again, if that asterisk was seen in an 
absolute dos style path (e.g., f:\blah\* ), then it's almost certainly a 
wildcard.  and if one is willing to ignore the yelping of people who 
routinely put asterisks in their filenames, then asterisk could always 
be assumed to be a wildcard.
  i was under the impression that the path processing was central to the 
cygwin dll, perhaps in the glob() function.  i doubt zip is implementing 
its own file globbing, so it seems that some additional code in the main 
glob() function for these issues that are peculiar to ms platforms would 
go pretty far in allowing cygwin to speak both flavors of slash.  these 
impressions are garnered from general unix experience rather than 
specific knowledge of the cygwin implementation though.


ps: i can live with issue 2 being ignored, but issue 1 (see below re 
absolute paths) impacts me almost every day.  my current workaround 
requires changing to the drive where the files live and using a relative 
path.  that definitely seems like a kludgey approach which shouldn't be 
necessary, but which currently is required.  if there is no maintainer 
for the zip tools, then i will go ahead and attempt this fix myself 
someday.  but i'd rather pass it along to the person with the deeper 
knowledge of the code.

_____ chosen by the Nechung Oracle Program [ ] _____

The credit belongs to those who are actually in the arena, who strive
valiantly; who know the great enthusiasms, the great devotions, and speed
themselves in a worthy cause; who at the best, know the triumph of high
achievement; and who, at the worst, if they fail, fail while daring
greatly, so that their place shall never be with those cold and timid
souls who know neither victory nor defeat.
  -- Theodore Roosevelt

_____________ not necessarily my opinions, not necessarily not. _____________

Christopher Faylor wrote:

>On Tue, Jun 26, 2001 at 11:05:27AM -0400, Fred T. Hamster wrote:
>>i have checked the faq and the mailing list and don't find the totally 
>>relevant answers, so here are the problems...
>>1) zip saves absolute paths in the zipfile.  for example, if i zip up 
>>"l:\source\lib_src\library\basis"/* into a zip file, all of the files in 
>>the archive start with "l:\".  this leads, on unzipping, for zip to want 
>>to write them back into "l:\" rather than unzipping into the current 
>>directory.  that is clearly a bad choice if my files on l:\ are somewhat 
>>better versions than those in the zip.
>> the infozip distribution doesn't exhibit this behavior in the dos 
>>port; instead, it chops off the absolutist part of the path and leaves 
>>it as "source\lib_src\library\basis".
>> note that using the -j flag to junk the paths is not appropriate; my 
>>zip files often contain 50-100 directories.  i definitely don't want 
>>them to all be dropped into the same directory on unzipping.
>Cygwin is a UNIX emulation environment.  The cygwin zip program is a
>UNIX port.  It probably doesn't know that \ is equivalent to /.
>We don't guarantee that every port of every utility that is distributed
>with cygwin will properly handle MS-DOS path syntax.  I don't think
>that many package maintainers even care about this.
>So, use forward slashes in your filenames.  That is one of the whole
>reasons for Cygwin -- the ability to use UNIX paths.
>If you don't want to use Cygwin's UNIX path name facilities then you
>should just be using a native zip port.

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]