Menu
▾
▴
#56 Unzip 61c23 does not unzip files into base directory with -d "/"
We are facing an issue with unzip 610c23, compiled from source file (http://antinode.info/ftp/info-zip/unzip610c23/). The source files are compiled in Centos 6.7 OS and Compiled with gcc 4.4.7 20120313 (Red Hat 4.4.7-18) for Unix (Linux ELF) on Mar 21 2017.
The issue is that when an extdir is specified with -d "/" the files in the zip archives are not uncompressed to "/", but are getting uncompressed to the current directory.
We have compiled the source code using the generic option:
1. make -f unix/Makefile generic
2. make prefix=/usr MANDIR=/usr/share/man/man1 -f unix/Makefile install
Would like to know if there is any switch that we need to specify at the time of 'configure'. Or is this the current behavior of the unzip functionality, a deviation from an earlier 6.0?
Here is the scenario:
1. cd /opt
2. unzip -o -q /opt/config.zip -d "/"
3. ls -al
this lists the contents of the config.zip file in the /opt directory, ideally the zip contents should have been uncompressed into the base directory ("/").
Request your help in this to find a solution for this issue.
Thanks for the report. I can reproduce it. It looks like an
unintentional behavior change someplace between 6.00 and 6.1c23. I'll
look into it.
Thank you very much Steven for the review and response
This appears to be what did it:
unix/unix.c:
/* 2014-03-10 SMS.
* Changed to create multiple directory levels, as needed.
The new ("new") code didn't consider "/". There's a revised
unix/unix.c here:
The changes seem plausible (to me), and the result seems to work in
my quick tests. If you could beat on it for a while, and let me know
what catches fire, I'd be grateful. If you don't break it, then the
changes should appear in the next pre-beta kit (and beyond).
Hi Steven,
You are an absolute gem !
The fix does works the way it is expected.
Thank you very much !
If that were true, then you would never have had the problem.
Thanks again for the report and the testing.
Hi Steven,
Hope you are doing good !
May i know when would the next build available for public with the fix for the below bug?
https://sourceforge.net/p/infozip/bugs/56/
With Regards,
Sathya
From: Steven Schweda [email protected]
Sent: Thursday, March 28, 2019 8:03 AM
To: [infozip:bugs]
Subject: [infozip:bugs] #56 Unzip 61c23 does not unzip files into base directory with -d "/"
You are an absolute gem !
If that were true, then you would never have had the problem.
Thanks again for the report and the testing.
[bugs:#56]https://sourceforge.net/p/infozip/bugs/56/ Unzip 61c23 does not unzip files into base directory with -d "/"
Status: open
Group: v1.0 (example)
Created: Wed Mar 27, 2019 09:18 PM UTC by Sathya Das
Last Updated: Thu Mar 28, 2019 02:20 AM UTC
Owner: nobody
We are facing an issue with unzip 610c23, compiled from source file (http://antinode.info/ftp/info-zip/unzip610c23/). The source files are compiled in Centos 6.7 OS and Compiled with gcc 4.4.7 20120313 (Red Hat 4.4.7-18) for Unix (Linux ELF) on Mar 21 2017.
The issue is that when an extdir is specified with -d "/" the files in the zip archives are not uncompressed to "/", but are getting uncompressed to the current directory.
We have compiled the source code using the generic option:
1. make -f unix/Makefile generic
2. make prefix=/usr MANDIR=/usr/share/man/man1 -f unix/Makefile install
Would like to know if there is any switch that we need to specify at the time of 'configure'. Or is this the current behavior of the unzip functionality, a deviation from an earlier 6.0?
Here is the scenario:
1. cd /opt
2. unzip -o -q /opt/config.zip -d "/"
3. ls -al
this lists the contents of the config.zip file in the /opt directory, ideally the zip contents should have been uncompressed into the base directory ("/").
Request your help in this to find a solution for this issue.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/infozip/bugs/56/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs: #56
Not known. As soon as I figure out a pending problem with exotic
(but non-Unicode) file names on Windows, it should follow pretty
quickly. But I don't know when that will happen.
Hi Steven,
Hope you are doing good !
Is there any update on when we could download the unzip binary with the fix for this issue?
With Regards,
Sathya
Nothing good. There's now one more problem in the queue, and I
haven't found much time to work on them lately. But slow progress
continues.
Sure, Steven. Thank you very much for the update.
Hi Steven,
Did you get a chance to push your changes into the build? We are planning for another product release and would like to know if your changes are in the master branch.
The change is in the development code, so it should be in the next
release, but I still don't have a date for that.