2
Vote

At unidentified conditions libopc fail with "Part /_rels/.rels does not exist.!\n" message

description

but unzip show "_rels/.rels" as archive member:

$ unzip -v 210648_summary_0_avg.xlsx
Archive: 210648_summary_0_avg.xlsx
Length Method Size Cmpr Date Time CRC-32 Name

 531  Defl:N      192  64% 1980-00-00 00:00 947bd5a8  _rels/.rels
 702  Defl:N      359  49% 1980-00-00 00:00 9c87e49e  docProps/core.xml
 267  Defl:N      163  39% 1980-00-00 00:00 8f99c3e9  docProps/app.xml
...
$

file attachments

comments

flr wrote Dec 19, 2012 at 8:27 PM

Thanks for reporting the issue.
Is it possible for you to attach the document in question?

wrote Dec 20, 2012 at 9:49 AM

vitaly_v_ch wrote Dec 20, 2012 at 9:49 AM

I compile my test application in following way:

$ gcc -o test \
            -g -Wall -Wextra -pthread -Wno-sign-compare -Wno-write-strings -Wno-deprecated -Wno-unused-parameter -Wno-unused-variable `xml2-config --cflags` -D_GNU_SOURCE  \
            test.c xlsx_editor.c \
            -lopc
$

and run:

$ ./test out.xlsx bEVM_9-LO.xlsx
Part /_rels/.rels does not exist.!
$

vitaly_v_ch wrote Dec 20, 2012 at 9:53 AM

PS: there are at least two base documents with same behavior: one created by MS Excel and one created by Libre Office.

flr wrote Dec 22, 2012 at 8:56 AM

-pthread ?!

Looks like you are using threads... Are you sure you have all concurrent calls to libopc properly mutexed?
Can you provide some sample code?

Thanks!

vitaly_v_ch wrote Dec 23, 2012 at 8:53 AM

In my application all calls to libopc are made from same thread. So all calls are properly mutexed :)

-pthread is artefact from main application.

all sample code you can extract from attachment XlsxEditor.zip. My sample code is stripped down from main application except that artifact :).

vitaly_v_ch wrote Jan 8, 2013 at 1:57 PM

Some hint:

I add following lines to findItem():
 OPC_ASSERT(i==j); 
 *pos=i;
  • {
  • for (i=0; i<items; i++)
  • fprintf(stderr, "%s: key1='%s', ((opcContainerPart*)array_)[%u].name='%s'\n",
  • func, key1, i, ((opcContainerPart*)array_)[i].name);
  • }
    return OPC_FALSE;
and get on stderr:

findItem: key1='rels/.rels', ((opcContainerPart*)array)[0].name='docProps/app.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[1].name='docProps/core.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[2].name='xl/sharedStrings.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[3].name='xl/styles.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[4].name='xl/workbook.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[5].name='xl/worksheets/sheet1.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[6].name='xl/worksheets/sheet10.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[7].name='xl/worksheets/sheet11.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[8].name='xl/worksheets/sheet2.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[9].name='xl/worksheets/sheet3.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[10].name='xl/worksheets/sheet4.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[11].name='xl/worksheets/sheet5.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[12].name='xl/worksheets/sheet6.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[13].name='xl/worksheets/sheet7.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[14].name='xl/worksheets/sheet8.xml'
findItem: key1='rels/.rels', ((opcContainerPart*)array)[15].name='xl/worksheets/sheet9.xml'
Part /_rels/.rels does not exist.!

So 'rels/.rels' really does not exist in array. It's by design or it's misbehavior of libopc?

wrote Feb 14, 2013 at 8:42 PM

wrote Aug 9, 2014 at 12:21 AM

kuperov wrote Aug 9, 2014 at 1:13 AM

On OSX 10.9.4, this happens for files saved by LibreOffice (v4.2.2.1) but not files saved by Excel.

Unzipping the .xlsx files shows _rels/.rels exists, but isn't being seen by libopc.