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.
Test file with './something' named files inside.
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.
> 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.