zip --symlink is incompatible with piped output
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
zip (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Hi folks,
As in the summary, if you use --symlink (-y) with the output piped to a process, it stops building the zip on the first symlink it encounters with an unhelpful error (as the user is not using -0 intentionally).
Here's the simplest test case I can build:
root@test123:
root@test123:
root@test123:
root@test123:
total 2
drwxr-xr-x 2 root root 4 Aug 20 09:10 asdf
-rw-r--r-- 1 root root 29 Aug 20 08:50 hello.txt
lrwxrwxrwx 1 root root 4 Aug 20 08:24 test -> asdf
root@test123:
adding: test
zip error: Invalid command arguments (zip -0 not supported for I/O on pipes or devices)
66.0 B 0:00:00 [93.4KiB/s] [<=> ]
I believe the issue is around line 575 of zipup.c... my understanding of the code is tenuous at best, but I think q is not reset when m is set to STORE:
l = issymlnk(a);
if (l) {
ifile = fbad;
m = STORE;
}
else if (isdir) { /* directory */
ifile = fbad;
m = STORE;
q = 0;
}
If I build with q = 0; in the if (l) block too, it appears to work (it complains that the file size changed while zipping, but zip does not error out, the zip file is created correctly), but I don't know what other problems this would introduce.
Not sure if anyone's maintaining this package so I don't want to put too much effort into it, I'll have a go at attaching a patch which I think fixes the issue, but again I'm not sure if it causes any new issues (and one probably wants to fix the warning about the file size changing at the very least).
no longer affects: | zip |
Status changed to 'Confirmed' because the bug affects multiple users.