Core Data app saving zero length files

  • Hi,

    I have a core data document based app that i wrote on Tiger, since
    moving to Leopard I've noticed that if I open an existing document,
    make no changes, and then save it, it saves a zero length file only,
    all the data is gone. If you make some changes to the document between
    open and save, then everything appears fine. (I'm using the XML store)

    I've rebuilt the app on Leopard, and it made no difference. I'm going
    to start digging through it, but has anyone seen anything similar?
    seems like it could be a serious issue.

    Thanks
    Simon
  • I've been able to re-pro this with a bare bones core data document app
    for the both the XML store and the binary store, the SQLLite store
    seems to be ok.

    You can download the re-pro case from http://www.pocketsoap.com/osx/emptyFile.zip

    run it, enter some text, select save, and choose either XML or binary
    format. look at the file, it'll be fine. now select save again, now
    the file will be 0k long. (radar #/5575683)

    Cheers
    Simon

    On Nov 1, 2007, at 10:01 PM, Simon Fell wrote:

    > Hi,
    >
    > I have a core data document based app that i wrote on Tiger, since
    > moving to Leopard I've noticed that if I open an existing document,
    > make no changes, and then save it, it saves a zero length file only,
    > all the data is gone. If you make some changes to the document
    > between open and save, then everything appears fine. (I'm using the
    > XML store)
    >
    > I've rebuilt the app on Leopard, and it made no difference. I'm
    > going to start digging through it, but has anyone seen anything
    > similar? seems like it could be a serious issue.
    >
    > Thanks
    > Simon
  • On Nov 1, 2007, at 10:44 PM, Simon Fell wrote:

    > I've been able to re-pro this with a bare bones core data document
    > app for the both the XML store and the binary store, the SQLLite
    > store seems to be ok.
    > You can download the re-pro case from http://www.pocketsoap.com/osx/emptyFile.zip
    > run it, enter some text, select save, and choose either XML or
    > binary format. look at the file, it'll be fine. now select save
    > again, now the file will be 0k long. (radar #/5575683)
    >
    That appears to be a genuine, rather unpleasant, bug.  Thanks for the
    report.

    A trivial workaround for now would probably be simply to implement:

    @implementation MyDocument

    - (IBAction)saveDocument:(id)sender
    {
        if ([[self managedObjectContext] hasChanges])
        {
    [super saveDocument:sender];
        }
    }

    This will at least prevent the user saving twice and triggering the
    bug.  Perhaps also:

    - (BOOL)validateUserInterfaceItem:(id < NSValidatedUserInterfaceItem
    > )item
    {
    if ([item action] == @selector(saveDocument:))
    {
      if ([[self managedObjectContext] hasChanges])
      {
      return YES;
      }
      return NO;
    }
    return [super validateUserInterfaceItem:item];
    }

    mmalc
  • >> I've been able to re-pro this with a bare bones core data document
    >> app for the both the XML store and the binary store, the SQLLite
    >> store seems to be ok.
    >> You can download the re-pro case from http://www.pocketsoap.com/osx/emptyFile.zip
    >> run it, enter some text, select save, and choose either XML or
    >> binary format. look at the file, it'll be fine. now select save
    >> again, now the file will be 0k long. (radar #/5575683)
    >>
    > That appears to be a genuine, rather unpleasant, bug.  Thanks for the
    > report.

    This bug affects subclasses of NSPersistentDocument using a store
    other than SQLite when saving "no changes" on 10.5.

    Malcolm has posted some workarounds, which I hope will carry people
    through until we can fix this.

    This bug does not affect non-document based Core Data applications.

    - Ben
  • I'd like to thank those on the list who identified this problem, and
    mmalc for the workaround solution.

    My shipping app (planbook- downloadable at www.hellmansoft.com) was
    bitten by this one, but with your help I was able to quickly patch my
    app and avoid further data loss among my users.

    This is, IMHO, a huge bug (my users lost hours and hours of work- of
    course they should have been backing up more frequently) and I hope
    that other core data document based application developers quickly
    patch their programs!

    Jeff

    Sent from my iPhone

    On Nov 3, 2007, at 5:01 PM, Ben Trumbull <trumbull...> wrote:

    >>> I've been able to re-pro this with a bare bones core data document
    >>> app for the both the XML store and the binary store, the SQLLite
    >>> store seems to be ok.
    >>> You can download the re-pro case from http://www.pocketsoap.com/osx/emptyFile.zip
    >>> run it, enter some text, select save, and choose either XML or
    >>> binary format. look at the file, it'll be fine. now select save
    >>> again, now the file will be 0k long. (radar #/5575683)
    >>>
    >> That appears to be a genuine, rather unpleasant, bug.  Thanks for the
    >> report.
    >
    > This bug affects subclasses of NSPersistentDocument using a store
    > other than SQLite when saving "no changes" on 10.5.
    >
    > Malcolm has posted some workarounds, which I hope will carry people
    > through until we can fix this.
    >
    > This bug does not affect non-document based Core Data applications.
    >
    > - Ben
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today