Opened 16 years ago

Closed 16 years ago

#39 closed defect (fixed) fails to validate zip files

Reported by: kyngchaos Owned by: hamish
Priority: major Milestone: 6.3.0
Component: Default Version: unspecified
Keywords: Cc: grass-dev@…
CPU: Unspecified Platform: Unspecified

Description uses "file -ib" on the zip file to check if it has the correct mime type. "-i" seems to be a very ambiguous way to specify the mime flag. The BSD version of file (at least on OSX) uses "-i" for the "do no classify" regular files option, and "-I" (uppercase) for the mime option, though has "-i" for mime listed as a legacy option. GNU file and old UNIX versions use "-i" for the mime option. SUS does not have mime as a minimum option to support.

It looks like all have the extended "--mime" flag. Attached is a patch to use that flag. There should probably be a way to handle the possibility of a system having a "file" command without any mime flag, but I don't know how to handle that, and it may not be critical.

Attachments (1) (497 bytes ) - added by kyngchaos 16 years ago.

Download all attachments as: .zip

Change History (8)

by kyngchaos, 16 years ago

Attachment: added

comment:1 by hamish, 16 years ago

could 'unzip -t' help?

what does the IEEE standard say about the -i file option?


comment:2 by kyngchaos, 16 years ago

I don't know why it was changed ([19303]), but it used to try unzipping immediately, and testing whether that failed. "unzip -t" tests by unzipping anyways before the real unzipping, thus wasting time (though it is only in memory).

comment:3 by kyngchaos, 16 years ago

Interesting - I was wondering why I didn't notice this before, I know I've converted SRTM since that change. I totally forgot to check older OSX versions. OSX 10.5 has "-I" as the mime flag. OSX 10.4, and probably previous versions, has "-i" as the mime flag.

what does the IEEE standard say about the -i file option?

Dunno, but the SUS standard (which OSX 10.5 now conforms to) has "-i" as the "do not classify regular files" option.

comment:4 by kyngchaos, 16 years ago

I guess my main concerns are:

  • the "--mime" flag is standard on modern systems - it looks like it.
  • I've noticed that people tend to avoid the double-dash long versions of flags, but I don't know if there is a technical reason other than less typing. In this case it avoids confusion in the -i/-I short flag.

If there are no objections to "--mime", I'll patch

comment:5 by hamish, 16 years ago

Cc: grass-dev@… added
Owner: changed from grass-dev@… to hamish
Status: newassigned

SUS says:

--mime is not mentioned.

re "why was it changed" in r19303: it never used zip to test, it was using ls to look for a file with a .zip extension. (input= refers to the tile name not the file name)

-ls -1 "$" | grep zip > /dev/null
-if [ $? -ne 0 ] ; then
+# really a ZIP file?
+if [ "`file -ib $`" != "application/x-zip" ] ; then
   echo "$ is no zip file."
   exit 1

for one thing "echo $ | grep zip" was always true.

Perhaps the reason for the test had to do with downloaders creating incomplete or 0 byte files, or having wrongly named files?

I've removed file and added a call to unzip -t in 6.3 trunk.

waiting to backport to 6.3.0's branch and close the bug until someone tests the change please.


comment:6 by hamish, 16 years ago

see r30046

comment:7 by hamish, 16 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.