Menu

#3 can not delete './name' files in zip archive

open
nobody
None
5
2004-12-08
2004-12-08
No

For details:
http://mail.gnome.org/archives/mc-devel/2004-December/msg00031.html.
In short: download
http://www.xs4all.nl/~bsarempt/python/p.zip and try to
delete './edit.html'. 'zip -d p.zip ./edit.html' fails
saying there's no './edit.html', while 'zip -d p.zip
[.]/edit.html' works. Replace (zip -r) however ignores
this and replaces './something' and 'something' in any
case.

Discussion

  • Doncho N. Gunchev

    Test file with './something' named files inside.

     
  • Ed Gordon

    Ed Gordon - 2007-10-08

    Logged In: YES
    user_id=1172496
    Originator: NO

    As the entry is ".\edit.html", this seems to be an improper archive as paths in archives are standardized to use the / as the separator. This does not match "./edit.html" in the delete command. Delete requires an exact match as it's matching the paths in the archive directly. The update command zip -r (update recurse) however tries to match operating system paths against archive paths and can do some path conversions while doing the match so these paths are equivalent and match. I think [.] is handled as a regular expression that can match zero characters, leaving "/edit.html" which I believe is handled the same as "edit.html" so that works.

     
  • Steven Schweda

    Steven Schweda - 2013-02-26

    > As the entry is ".\edit.html", this seems to be an improper archive as
    > paths in archives are standardized to use the / as the separator. [...]

    Hmmm. I see "./", not ".\" in the archive. To me, the problem
    appears to be that unix.c:procname() passes the name through
    unix.c:ex2in(), and ex2in() does this:

    while (*t == '.' && t[1] == '/')
    t += 2; /* strip redundant leading "./" sections */

    transforming a name like "./edit.html" into "edit.html", which then
    fails to match the "./edit.html" in the archive. The "[.]/name"
    work-around seems to work, but perhaps not as explained before.

    Zip normally does this sort of redundancy reduction when it creates
    an archive, so I would not expect to see names like these in an archive
    which Zip creates. For example:

    $ zip fred.zip ./a.txt
    adding: a.txt (stored 0%)

    $ unzip -l fred.zip
    Archive: fred.zip
    Length Date Time Name
    --------- ---------- ----- ----
    5 02-26-2013 16:19 a.txt
    --------- -------
    5 1 file

    $ zip fred.zip ./a.txt ./././a.txt
    zip warning: first full name: ./././a.txt
    second full name: ./a.txt
    name in zip file repeated: a.txt

    zip error: Invalid command arguments (cannot repeat names in zip file)

    Whether it makes sense to be using ex2in() in this situation is
    another question, which has not yet been resolved, lo these many years
    later.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.