zipfile sub-option 'saving(... , replace)' not working with quoted target file name?

[Daniel Bela]

Dear Statalist community,

I just encountered a behavior with the zipfile command in Stata (I tested this in both Stata for Windows and Stata for Linux, version 15.1, fully patched) that I did not expect. On my machines, the suboption replace to the argument saving() does not seem to have an effect if I enclose the target file name in double quotes. Consider the following example code:

sysuse auto , clear
save "testfile1.dta" , replace
save "testfile2.dta" , replace
zipfile "testfile1.dta" "testfile2.dta" , saving("both_testfiles.zip") // <-- works
zipfile "testfile1.dta" "testfile2.dta" , saving(both_testfiles.zip , replace) // <-- works as expected
zipfile "testfile1.dta" "testfile2.dta" , saving("both_testfiles.zip" , replace) // <-- doesn't work; sub-option 'replace' does not seem to have an effect

The second invocation of zipfile yields

file already exists
    You must specify option replace to overwrite the existing file.

Is this the desired behavior? As I understand, this makes it impossible to create ZIP archives with spaces in their names (not that I would like to do so). Do you think I should raise this as an issue to Stata Technical Services, or do I miss something?

Kind regards
Bela

[William Lisowski]

I note that nothing in the documentation for zipfile suggests that spaces can be included in the zipfilename argument to the saving option. The single comment on quoting is in the command syntax section of the documentation.

Syntax

    Add files or directories to a zip file

        zipfile file|directory [file|directory] ... , saving(zipfilename[,
                replace])


    Extract files or directories from a zip file

        unzipfile zipfilename [, replace]


    Note:  Double quotes must be used to enclose file and directory if the name
           or path contains blanks.  file and directory may also contain the ?
           and * wildcard characters.

[Daniel Bela]

I note that nothing in the documentation for zipfile suggests that spaces can be included in the zipfilename argument to the saving option. The single comment on quoting is in the command syntax section of the documentation.

After a second read, I agree that the documentation does not make explicit that spaces in file names or quoting are allowed in the saving() option. To me (and maybe others?), this is irritating at least. It's a deviation from Stata's "default' filenaming conventions, stating:

All operating systems allow blanks in filenames, and so does Stata. However, if the filename includes a blank, you must enclose the filename in double quotes.

In my opinion, the help file for zipfile should be explicit about deviating from the default, if this is the desired behavior. The attentive reader probably recognizes the slight difference between saving(filename) (as of, for instance, the option to the command graph) and saving(zipfilename), but not everyone spots such details.

And, as another remark: The error message that is presented when using quotes in the saving() option to zipfilename (see OP) clearly is misleading.

Regards
Bela

[daniel klein]

The attentive reader probably recognizes the slight difference between saving(filename) (as of, for instance, the option to the command graph) and saving(zipfilename), but not everyone spots such details.

This is the same as referring to depvar instead of varname; it should not have any technical implications. The reported behavior is definitely a bug suspect and should, in my opinion, be reported to tech-support.

Best
Daniel

[William Lisowski]

I agree with both posts #3 and #4. I had an alternative hypothesis, but on inspection of zipfile.ado, it struck me that the code may be too clever by half. And indeed, the following example suggests that if the comma is not preceded by a space, zipfile works as intended. (!!!) (Post #1 demonstrated that a space is allowed before the comma if the filename is not quoted.) And regardless of spacing, if the file does not already exist zipfile doesn't care that it didn't find the replace option.

. zipfile gnxl1.txt gnxl2.txt, saving("both.zip" , replace)
    adding: gnxl1.txt (deflated 15%)
    adding: gnxl2.txt (deflated 15%)
total processed:  2
        skipped:  0
       archived:  2

. zipfile gnxl1.txt gnxl2.txt, saving("both.zip" , replace)
file already exists
    You must specify option replace to overwrite the existing file.
r(130);

. zipfile gnxl1.txt gnxl2.txt, saving("both.zip", replace)
    adding: gnxl1.txt (deflated 15%)
    adding: gnxl2.txt (deflated 15%)
total processed:  2
        skipped:  0
       archived:  2

So this is a workaround, or maybe just a kludge, to solve your immediate problem, Can you take a few moments to report it to Stata Technical Services as documented at https://www.stata.com/support/tech-support/contact/ ? You can cover most of the information requested by giving them the URL for this discussion.

[Daniel Bela]

Hi again,

thanks for spotting the spacing issue, I did not even think about my habit of preceding spaces before option commas could have to do with this. Thus, my full example for demonstration purposes is as follows:

sysuse auto , clear
save "testfile1.dta" , replace
save "testfile2.dta" , replace
zipfile "testfile1.dta" "testfile2.dta" , saving("both_testfiles.zip") // <-- works
zipfile "testfile1.dta" "testfile2.dta" , saving(both_testfiles.zip, replace) // <-- works as expected
zipfile "testfile1.dta" "testfile2.dta" , saving(both_testfiles.zip , replace) // <-- works as expected
zipfile "testfile1.dta" "testfile2.dta" , saving("both_testfiles.zip", replace) // <-- works as expected
zipfile "testfile1.dta" "testfile2.dta" , saving("both_testfiles.zip" , replace) // <-- doesn't work; sub-option 'replace' does not seem to have an effect

This code, interestingly, works in Stata 13 and Stata 14, but not so in Stata 15 (where the last -zipfile- invocation fails). This makes me even more think that we see unintended behavior here.

I reported this to Technical Services and will report back here with their response. Thanks for your comments on this, William Lisowski and daniel klein.

Regards
Bela

[Daniel Bela]

Hi once more,

I received an answer from Stata Technical Services:

Thank you for reporting this bug, we have been able to replicate it with the good examples you sent. I have forwarded this bug to the developers and they let me know they will resolve this issue and push out a fix in an update.

So it looks like the issue will be resolved with one of the next updates.

Thanks to all
Bela

[Ijaz Ali]

Hello to all,
I am trying to unzip a file, "LFSDATA2010-2014.zip" . I am using Stata 14.0. But Stata returned the message
"cannot open LFSDATA2010-2014.zip or LFSDATA2010-2014.zip.
zip could not perform unzip"

I used these Syntax,

cd "D:\rough"

unzipfile "LFSDATA2010-2014.zip",replace

unzipfile "LFSDATA2010-2014.zip"


Note: The file contains four years data in SPSS format, I mean four sub spss files.