File: ToDo

package info (click to toggle)
unzip 5.52-9etch1
  • links: PTS
  • area: main
  • in suites: etch
  • size: 5,776 kB
  • ctags: 7,140
  • sloc: ansic: 49,152; cpp: 3,978; makefile: 2,310; asm: 1,583; sh: 91
file content (179 lines) | stat: -rw-r--r-- 6,803 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
================================
For UnZip 6.0/6.1/who knows:
================================

   o implement handling of file sizes beyond the 32-bit limit of
     2GByte (resp. 4GByte), using the new 64-bit extra field extensions
     as defined by PKWARE (this will not get implemented for the present
     16-bit ports - plain DOS and OS/2 1.x)

        top of the list for 6.0!
        UnZip 6.0 is now under development, first betas for Win32 and Unix
        are available

   o add multi-part zipfile handling

        major feature for 6.0!

        could happen for 6.0 - 10/8/2004 EG

   o better support for multilingual uses and different codepages;
     support unicode (UTF-8 coded) filenames and comment texts

        a requested feature getting more and more important,
        maybe in 6.1

   o add new low-level, binary API; rewrite "normal" (command-line) UnZip
     to use it

        maybe soon (maybe 6.1)

   o use (simple!) configure script in combination with Unix Makefile

        very soon (6.0 or 6.1)

        may be needed in 6.0 to autodetect large file support - 10/8/2004 EG

   o add precautions against extracting files outside the tree below
     the current directory resp. the specified extraction folder.
     (automatically remove absolute path specs from zip entries; emit
      warnings when traversing outside the extraction tree...)

        done as of version 5.51

   o MSDOS/WIN32/others: detection of "reserved" names (= names of character
     devices, or system extensions that look like a characters device driver)
     at runtime; with the goal of emitting "meaningful" error messages and/or
     rename queries.
     (Currently, these reserved names are catched as "non-deletable files".
      On MSDOS and WIN32, when the RTL stat() function allows to identify
      character devices, the "reserved" names are automatically prefixed with
      an underscore.)

   o redesign "file exists -- is newer/older -- overwrite/skip/rename"
     logic in extract.c and the corresponding system specific mapname()
     services; to prevent superfluous decryption key prompts for entry
     that will be skipped, later.

   o rewrite to use fread/fseek/etc.  [eventually: test
     write(bytes) vs. fwrite(words), especially on Crays/Alphas]

        soon (probably in conjunction with multi-part handling)

   o incorporate new backfill version of inflate()

        wait for zlib version

   o check NEXTBYTE for EOF in crypt.c, funzip.c and explode.c, too

        whenever

   o add option to force completely non-interactive operation (no queries
     for overwrite/rename, password, etc.); also allow some sort of non-
     interactive password provision?  (file? command-line? env. variable?)

        someday?

   o add testing of extra fields (if have CRC)

        later

   o rewrite to allow use as a filter

        way, way later...

   o add Unix hard-link support?

        way, way later...

   o add ".ini" file support as a (more elaborate) alternative to the presently
     supported preconfiguring abilities via special environment variables
     (UNZIP on many systems...)?

        way, way later (if ever)...

   o add option to search zipfile contents for a string and print the
     results? ("zipgrep" option--e.g., unzip -g or unzip -S) (easy for
     fixed strings, hard for wildcards/true regex's)

        way, way later, if at all...probably use libregex

   o add -y "display symlinks" option to zipinfo?  various sorting options?
     (-St date/time, -Sn name)?

        who knows

   o add "in-depth" option to zipinfo? (check local headers against
     central, etc.)--make it a better debugging tool (or just create
     zipfix)

        who knows (zip -F, -FF already exist)

Some maintenance or OS specific topics for 6.0 release:

   * add "unix-style-path -> partitioned-dataset filename" conversion
     to MVS port

   * should we add support for (null) entry names (empty entry name field), to
     conform to the PKWARE specification?


=======================================

Requested features:

 - extract or exclude on basis of UID [Armin Bub, Armin.Bub@bk.bosch.de, 970904]

=======================================

   o miscellaneous little stuff:  whenever
     --------------------------

 - add support for setting directory time stamps to win32 port. This requires
   a solution similar to the UNIX SET_DIR_ATTRIB optional code; maybe, it could
   be combined with the delayed restoring of directory ACLs. Unfortunately,
   the simple version used in the OS/2 case (setting dir time stamp just after
   creating the directory) does not work, because WinNT updates directory
   change times whenever the directory content gets modified (addition,
   deletion, rename, file change), at least for NTFS file systems.
   (SPC, 2000-11-16)

 - change DOS -f/-u stuff to use DOS API for getting filetimes, not stat()

 - add (-N?) option to lose all user input and/or switch to "(*input)()"
   function, replaceable by UzpAltMain() param
 - add -@ option to read from stdin (zip) or from file (PKZIP)?  (go32 built-in)
 - add -oo option to overwrite OS/2 and DOS system and hidden files, too
 - add option to compute MD5 checksum on files and/or on entire zipfile?

 - decide whether to use WinGUI "skipping" diagnostics in extract.c
 - combine "y/n/A/N" query/response stuff into unified section with query
    function(s) (InputFn?)
 - disable ^V code in remaining mapname() routines

 - change filename-matching logic so case-insensitive if case-sensitive fails?

 - allow multiple dir creation with -d option? [Bob Maynard]

 - use gcc -pg, gprof to do profiling on unzip

 - Doug Patriarche (doug.patriarche.bvdhp01@nt.com) Northern Telecom Canada Ltd.
    "I need to do a port of zip/unzip for Wind River Systems' VxWorks OS"
    [GRR:  15 March 95 -> "early June"]


Features from old BUGS file (mostly duplicates of other entries above):

 - ignore case for internal filename match on non-Unix systems, unless file-
    specs enclosed in single quotes
 - modify to decompress input stream if part of a pipe, but continue using
    central directory if not (BIG job!)--extended local header capability
 - add zipinfo option(s) to sort alphabetically, by date/time, in reverse, etc.
 - when listing filenames, use '?' for non-printables? [Thomas Wolff, 92.6.1]
 - add zipinfo "in-depth" option? (check local vs. central filenames, etc.)
 - create zipcat program to concatenate zipfiles
 - add -oo option (overwrite and override)?  no user queries (if bad password,
    skip file; if disk full, take default action; if VMS special on non-VMS,
    unpack anyway; etc.)
 - add -Q[Q[Q]] option (quiet mode on comments, cautions, warnings and errors)?
    forget -oo, or make synonym?  Default level -Q?