Re: odt-export fails

[Jambunathan K <kjambunathan@gmail.com>]

> Hello Jambunathan,
>
> I do not have the odt document open.

Ok.

> From the *Message* buffer, it seems that zip is looking for the odt file in
> c:\Users\...\AppData\Temp\..., but the file is not present

,----
| > Creating odt file...
| > Running zip -mX0 org-odt-export.odt mimetype
| > zip warning: name not matched: mimetype
| >
| > zip error: Nothing to do! (org-odt-export.odt)
| >
`----

No. Zip is trying to create an ODT file. 

It starts with putting the "mimetype" file in the
org-odt-export.odt. That is what the command above does. Unfortunately
it is not able to find the mimetype file. See the warning message
above. That is why you get an error.

,----
| > Switching to directory c:/Users/977315/AppData/Local/Temp/odt-7628lrW/
`---- 

This is the directory (it is a temporary directory) where the mimetype
file and various files are created.

,----
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/meta.xml
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/mimetype
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml
| > Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml
`----

The above messages show that the mimetype file and all the XML files are
indeed created.

I suggest you do this:

1. Export with "C-c C-e O" and let the error happen
2. M-x shell RET and in the shell prompt, do the following steps.
3. Switch to the temporary directory using "cd"
4. Check what files are in that directory with "ls"
5. Make sure that you are able to see all the above files. You may want
   to check that the mimetype file is also there.
6. Run the following command,
   
    $ zip -mX0 org-odt-export.odt mimetype

   If the mimetype file is there, the above command should succeed and
   will create org-odt-export.odt file for you.

7. If you don't see the mimetype file in step 5, it is possible that
   someone (the OS) is removing the temporary files very quickly. In
   that case, you can try using your own temporary directory with the
   following command

        (setq temporary-file-directory "~/tmp/")

   and try exporting it again.

This is a strange issue and I am making the best possible guess based on
the information that you have provided.

ps: What version of Windows are you using? Does the OS or any app on
your desktop aggressively remove temporary files?


> In the org-odt-save-as-outfile let* block from which the error is thrown
> (let* ((target-name)
>         (target ...)
>         ...)
> zip-commands)
>
> zip-commands are looking for the *.odt file to zip together with the
> mimetype file.  But the *.odt file
> is not there.
>
> The only thing that is there is the content.xml, that contains the
> the *.org file's text.  In fact, in the code, I don't see anything being
> done with the xml files.  They are created, and then killed.
>
> I am including the trace from the *Messages* buffer.
> **** Trace begin
> Export buffer:
> Exporting to ODT using org-lparse...
> Using vacuous schema
> LaTeX to MathML converter not available. Using dvipng instead.
> Exporting...
> Using vacuous schema
> ODT export done, pushed to kill ring and clipboard
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/meta.xml
> Using vacuous schema
> Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml...
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/mimetype
> Using vacuous schema
> Switching to directory c:/Users/977315/AppData/Local/Temp/odt-7628lrW/
> Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml...
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml
> (No changes need to be saved)
> Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml...
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml
> Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml...
> Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml
> Using vacuous schema
> (No changes need to be saved)
> Creating odt file...
> Running zip -mX0 org-odt-export.odt mimetype
> zip warning: name not matched: mimetype
>
> zip error: Nothing to do! (org-odt-export.odt)
>
> Entering debugger...
> Back to top level.
> **** Trace end
>
> Mirko
>
> On Sat, Feb 25, 2012 at 8:28 AM, Jambunathan K <kjambunathan@gmail.com> wrote:
>>
>> The backtrace is along the expected lines. The zip command is failing
>> for some reason.
>>
>> Did you look at the *Messages* buffer? It is likely to give some clue on
>> why the zip command is failing.
>>
>> Btw, if you have "cvd-modeling-proposal.odt" already open in an external
>> application like LibreOffice, you may want to close the file first,
>> before exporting. Closing the file will ensure that the file is not
>> locked and available for re-writing.
>>
>>> Hello:
>>>
>>> This is on Windows 7 Emacs 23.3.1, org-version 7.8.03.  (I installed
>>> org-mode inside cygwin's shell).
>>>
>>> Here is the backtrace:
>>>
>>> Debugger entered--Lisp error: (error "Unable to create odt file (12)")
>>>   signal(error ("Unable to create odt file (12)"))
>>>   error("Unable to create odt file (%S)" 12)
>>>   (or (zerop exitcode) (ignore (message "%s" err-string)) (error
>>> "Unable to create odt file (%S)" exitcode))
>>>   (lambda (cmd) ... stuff deleted
>>>  
>>> org-odt-save-as-outfile("c:/Users/977315/Documents/projects/low-pressure-flow/workbooks/shh+cvd-design-tool-proposal/cvd-modeling-proposal.odt"
>>> ... more stuff deleted ...
>>>   org-do-lparse(nil nil nil nil nil nil)
>>>   org-lparse("odt" "odt" nil nil nil nil nil nil)
>>>   org-export-as-odt(nil)
>>>   call-interactively(org-export-as-odt)
>>>   org-export(nil)
>>>   call-interactively(org-export nil nil)
>>>
>>> The backtrace refers to a a non-existent odt file (see call to
>>> org-odt-save-as-outfile).  Does the call stack look ok to you?
>>>
>>> Thanks,
>>>
>>> Mirko
>>>
>>>
>>
>> --