Opened 15 years ago
Closed 15 years ago
#39 closed defect (fixed)
r.in.srtm fails to validate zip files
|Reported by:||kyngchaos||Owned by:||hamish|
r.in.srtm 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.
Change History (8)
by , 15 years ago
comment:1 by , 15 years ago
comment:2 by , 15 years ago
I don't know why it was changed (), 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 , 15 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. http://en.wikipedia.org/wiki/File_%28Unix%29#Usage
comment:4 by , 15 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 r.in.srtm.
comment:5 by , 15 years ago
|Status:||new → assigned|
--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 "$FILE.hgt.zip" | grep zip > /dev/null -if [ $? -ne 0 ] ; then +# really a ZIP file? +if [ "`file -ib $FILE.hgt.zip`" != "application/x-zip" ] ; then echo "$FILE.hgt.zip is no zip file." exit 1 fi
for one thing "echo $foo.zip | 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?
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 , 15 years ago
comment:7 by , 15 years ago
|Status:||assigned → closed|
could 'unzip -t' help?
what does the IEEE standard say about the -i