Hi

        I don't know what will be happening. But I think that if in other
computer or program LO 3.3.2 you don't have problem to use the
file, ...the file ins't corrupted and newer LO neither.

        I think that Vista or the OpenOffice 3.1.0 would lose something as
program by whatever way and / or the computer where you have it
installed has something fisical bad.

        I suggest you a probe (If you have some free time):

        Why not install again OpenOffice 3.1.0 in other computer and try to use
the file? (With and without new Vista installation)

Regards,

Jorge Rodríguez

___________________

El vie, 12-08-2011 a las 16:04 +1000, Simon Cropper escribió:
> *** 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
> 

-- 
Atentamente,

Jorge Rodríguez


-- 
For unsubscribe instructions e-mail to: users+h...@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

Reply via email to