Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]

*** Jorge, as I respond to your email I find out a range of things of 
note, as I try and support or refute my ideas. It is enlightening to 
read the entire post but you can just as easily jump to >>HERE<< ***

Sorry Jorge,

I suppose it is confusing.

The problem is the corruption due to the insertion of the image is not 
immediately obvious. Then as the file becomes more progressively more 
corrupt.

The sequence was like this
1. Cut-and-paste data
2. Reinsert images and objects
3. Other stuff...
4. Issue with comments noted

What surprised me was after recreating a clean file for use I then ended 
up with an error popping up. No comments were found anywhere.

So I stripped the file back to the individual components -- data, 
format, images, etc. Adding each one separately then testing extensively.

On adding the images I noted some funny stuff happening to the file 
size. as I saved, re-saved, deleted sheets, re-saved, etc... I noticed 
that the file showed more problems rendering images (images disappeared 
as well as references to files disappeared). Soon afterwards the file 
had problems saving after deletion of the sheet.

So I presume that the images caused the corruption of the structure, the 
problem progressively got worse, then the comments field tipped the 
scale and caused the error in saving after the deletion of the sheet. 
anyway that seems as plausible as any explanation I have seen already.

As stated I am unable to reproduce these errors on new files. despite 
trying repeatedly for hours.

As stated previously I was able to shake the problem by 
cutting-and-pasting the data into the spreadsheet. This included 
everything images and all. I could not trigger the error despite hours 
of testing. Consequently I posted the 'solution' to this thread.

After several hours of adding and deleting data, the problem reappeared.

As stated I then recreated the file including data-formula-format, minus 
other objects then progressively built up the file until it mimicked the 
original. Each step I tested, retested and checked yet again. In the end 
I noted things got 'wonky' after insertion of the images-artwork. this 
did not particularly make sense to me but I persisted in splitting the 
objects being inserted in the document until I could identify the 
culprit. This eventually identified a single image (originally a GIF 
that was converted to a PNG). Add this image to the sheet and 
progressively problems appear. If I recreate a PNG file using GIMP and 
insert this I can't get the problems to appear. This is using the same 
file, data and files - side by side. Very confusing.

There is only two conclusions
(a) that the file is corrupt, something corrupted it and at present the 
first thing I notice a problem occurring after it is inserted is this 
image.
(b) that LO accesses and manipulated the file incorrectly. In other 
words their is a bug in the code.

As I am not inclined to post a file with all my financial details on the 
Internet, and I have no other versions of LO around to test the second 
theory I am in a quantry.

>>HERE<<<

Well... As it turns out I have an old version of OpenOffice 3.1.0 
OOO310m11 (Build: 9399) lying around on an old Windows Vista laptop I 
was unaware about.

Exact same file (except for one computer is accessing the local drive 
and the other a SAMBA network drive)...
- LO baulks with the error "blah blah unable to write"
- OO does not! Whaaaa?

Alright I am on Ununtu. I opened a copy of the file via nautilus from a 
local drive mounted using fstab - the error occurs. If I use nautilus to 
locate and access the same samba share the windows machine used - the 
error occurs.

Somehow I am relieved.

OK, I test using another machine ubuntu-ubuntu using LO 3.3.2, both via 
a NFS mount and Samba share. Both sheet deletions and saved worked on 
the exact same file that my machine baulks with - that is the error did 
not occur.

I am bloody confused! The problem is "computer specific and file 
specific". As part of the entire exercise I completely uninstalled every 
LO related package and reinstalled them with all the dependencies.

I have check and rechecked the file permissions, ownerships and groups. 
Nothing untoward.

Anyone got any ideas? if the disk was damaged then then all computer 
would complain. This leaves be with some conflict or background process 
that is interfering with the operation I am trying to do... you know the 
operation I can reproduce on any other file, except when I cut and paste 
data from the original file. Sound a lot like a corrupt disk, but how 
does the NFS and Samba Shares NOT trigger this error.


On 12/08/11 14:28, jorge wrote:
> Hi
>
>         I'm some confused. Was the comment or the image the problem ? or Both ?
>
> Regards,
>
> Jorge Rodríguez
> _____________
>
>
> El vie, 12-08-2011 a las 13:52 +1000, Simon Cropper escribió:
> > Hi Everyone,
> >
> > I have been doing some follow-up investigations that I thought you might
> > like to be made aware.
> >
> > First, why? Well after testing the file that I recreated by copying the
> > text, formula and styles I could not cause the error to occur again.
> > This is what I reported yesterday. I then proceeded with importing the
> > few images and 'artwork' objects from the old file to the new. After
> > several saves and sheet manipulations I noticed the file became unstable
> > again.
> >
> > The outcome of my investigation was that one of the image files used on
> > one of the sheets had become corrupted* and adding this file in caused
> > the file to become unstable - eventually exhibiting the problem I
> > mentioned about not being able to save after a sheet was deleted. These
> > 'corrupted' files are relatively benign with the error only becoming
> > apparent *once* you attempt to delete the sheet. So somehow the error
> > caused problems with the broader 'workbook' structure not the sheet
> > structure. Although I compared files between different versions of the
> > file the XML were too varied (usually style names and definitions;
> > content was identical).
> >
> >      * note I say corrupted but it rendered OK and only resulted
> >      in the observed behaviour one a sheet is deleted. I 'deem' it
> >      corrupted as once replaced with a clean version render and
> >      saved as a new file by GIMP, the problem disappeared.
> >
> > The error was with the particular corrupt objects. On recreating new
> > images and inserting them into a file I have not been able to trigger
> > any problems. If I cut-and-paste from the original 'corrupt' file the
> > file becomes unstable after a few saves and sheet manipulations.
> >
> > So the steps for salvage is...
> > 1. recreate a new file with the exact number of sheets as the original.
> > Ensure each sheet names are the same.
> > 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the
> > content being placed in the new file to text, numbers, date&  time,
> > formulas and formats.
> > 3. If you have images in the file. Recreate / Save using another
> > package. As mentioned I used GIMP.
> > 4. Insert new copies of the images into file. *Don't* cut-and-paste
> > objects from the old file.
> > 5. If you have any lines, text boxes and artwork; recreate them from new.
> >
> > During this process...
> > - Save as a new version (+tabs, +data, +images, +other objects)
> > following each step.
> > - Test each version thoroughly before proceeding.
> > - Only add one object at a time, so if something goes wrong you can
> > isolate the problem component.
> > - To check it is not a bug try and recreate with a fresh file.
> >
> > A couple of quick notes that may be valuable to others...
> > - ODS files are archives. Use an archive facility to extract the data
> > inside. Inspect the contents in the folders to see what is different.
> > - On every 'Save as' the file size changes. This is not due to changes
> > in the file contents, but rather in changes in how the components of the
> > file is compressed/archived. If you open a file, add objects then save,
> > the file size with be so big. Open that file and "Save as" a new name
> > and the file will be a different size. If you extract the files the
> > contents of all the files and directories are identical. It is just the
> > internal archive facility in LO will decide the best compaction routine
> > based on what it encounters.
> > - The content.xml file can be quite large and has no internal
> > end-of-line characters. This make it difficult to open and be parse by
> > various text editors, xml viewers and comparison facilities. To insert a
> > EOL character after the end of each tag (i.e.>), I used the following
> > command in the terminal (requires Linux).
> >
> >      cat content.xml | sed -e 's/>/>\n/g'>  content_with_linebreaks.xml
> >
> >      cat just spews the content of the text file to the standard output.
> >      I then pipe it to sed, where I used regular expressions to find '>'
> >      and replace every instance of it with '>\n'. I then compared the
> >      contents with Diffuse.
> >
> >
> > On 11/08/11 14:44, jorge wrote:
> > > Congratulations,... it was an interesting investigation.
> > >
> > > Regards,
> > >
> > > Jorge Rodríguez
> > > ______
> > >
> > > El jue, 11-08-2011 a las 11:50 +1000, Simon Cropper escribió:
> > > > On 10/08/11 16:41, Simon Cropper wrote:
> > > > > *The upshot*
> > > > >
> > > > > Unless someone recognised these symptoms and can put forward some ideas,
> > > > > I am treating this as a corrupt file. I have drawn this conclusion
> > > > > because (a) I can only reproduce the error on the effected file, (b) the
> > > > > comment insert/delete trick is suggestive but not consistent (or at
> > > > > least from what I can tell) - random sheets cause the file save error if
> > > > > comments are inserted; inserting comments into new sheets also trigger
> > > > > the error.
> > > > >
> > > > > I just hope that recreating this file does not corrupt the new file as I
> > > > > will need to copy blocks of text, numbers and formulas.
> > > >
> > > >                *My attempts at recreating a clean file*
> > > >
> > > > ATTEMPT 1
> > > >
> > > > Created a new file with one less tab. All tabs were named the same as
> > > > the original. I then cut-and-paste all the data from the original to
> > > > this newly created file. This took about 10 minutes.
> > > >
> > > > The problem is that all tab / sheet references after the omitted sheet
> > > > moved across one. Despite the formula referencing the sheet name, the
> > > > name is actually just a human readable cue for the underlying sheet
> > > > number. So sheet Accounts (sheet #17 on the original file), which
> > > > pointed to 'accounts lookup list' now points to the Tax sheet, which was
> > > > #18 but is now #17 in the new file.
> > > >
> > > > ATTEMPT 2
> > > >
> > > > Created a new file with exactly the same number of tabs.  All tabs were
> > > > named the same as the original. I then cut-and-paste all the data from
> > > > the original to this newly created file. This took about 10 minutes.
> > > >
> > > > Then with baited breath I deleted the unrequired sheet that triggered
> > > > this journey in the first place and clicked save. *It worked* - that is,
> > > > it saved without triggering a write error.
> > > >
> > > > I have checked - (a) all data is intact, and (b) all the formulas are
> > > > working. :)

--
Cheers Simon

   Simon Cropper
   Principal Consultant
   Botanicus Australia Pty Ltd
   PO Box 160, Sunshine, VIC
   W: www.botanicusaustralia.com.au

--
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted