[Kmymoney-devel] .xml save not working

[Thomas Baumgart]

Hi,

on Friday 09 October 2009 Alvaro Soliverez wrote:


> On Fri, Oct 9, 2009 at 5:08 AM, Cristian Oneţ 
<onet.cristian at gmail.com>wrote:
> > On Fri, Oct 9, 2009 at 8:36 AM, Thomas Baumgart <thb at net-bembel.de> wrote:
> > > Hi,
> > >
> > > on Thursday 08 October 2009 Cristian Oneţ wrote:
> > >> În data de Miercuri 30 Septembrie 2009 06:02:47 Alvaro Soliverez a
> >
> > scris:
> > >> > Hello all,
> > >> > just so you know, using a format with .xml extension results in the
> >
> > Save
> >
> > >> > command not working.
> > >> > When you hit save, it seems to work, but if you close and reopen the
> > >> > file, nothing has been done.
> > >> > I'm not sure I will have time to look at it soon, so if anybody
> > >> > wants
> >
> > to
> >
> > >> > jump in, you are welcome.
> > >> >
> > >> > Regards,
> > >> > Alvaro
> > >>
> > >> I found out so far that the problem is that the KSaveFile is not
> > >> opened when saving as xml and the file already exists. This causes the
> > >> save opration to fail. A good place to open the file would be
> > >>  KMyMoneyView::saveFile (do it always) but that seems to brake saving
> > >> as kmy file. So I'll have to investigate a bit further but if these
> > >> observations give a clue to those of us who know the application
> > >> better and they can fix this faster, please do that ;).
> > >
> > > take a look at kmymoneyview.cpp lines 1127 .. 1163 and compare them
> >
> > against
> >
> > > the KDE3 version. You can clearly see, that the file is not opened if
> > > it exists:
> > >
> > >      if(fi.exists()) {
> > >        fmode |= fi.permission(QFile::ReadGroup) ? 040 : 0;
> > >        fmode |= fi.permission(QFile::WriteGroup) ? 020 : 0;
> > >        fmode |= fi.permission(QFile::ReadOther) ? 004 : 0;
> > >        fmode |= fi.permission(QFile::WriteOther) ? 002 : 0;
> > >        if(fi.groupId() != static_cast<uint>(-2))
> > >          gid = fi.groupId();
> > >      } else {
> > >        qfile.open();
> > >      }
> > >
> > > This is completely different in the KDE3 version. The trick with the
> >
> > basic
> >
> > > block and the automatic deletion of the KSaveFile object as done in
> > > KDE3
> >
> > does
> >
> > > not work here anymore. One might use the KSaveFile::finalize() method
> > > to
> >
> > close
> >
> > > the file to be able to change the owner of it.
> > >
> > > If you don't think you can fix this yourself, please let me know and
> > > I'll
> >
> > take
> >
> > > a look at it next week. Won't have time before.
> >
> > Now I get it. So this was messed up during the 'make it compile on
> > KDE4' phase. When encountering such problems I always check the KDE3
> > version to spot possible problems in the differences. I don't know how
> > I missed this difference, thanks for pointing this out this is the
> > kind of hint I expected to get after my previous mail :).
> 
> Ok, so there is some karma in this bug, because it was me porting that part
> of code, and I got bitten by it. :)
> 
> I remember adding the qfile.open() because if the file does not exist, the
> subsequent calls wouldn't open automatically like in Qt3.
> 
> Why is it that this fails with .xml files, but not with .kmy files?

The file should be opened no matter what format is used. For XML this opened 
file object will be used. For compressed and encrypted formats, the file will 
be closed and re-opened. That happens in saveToLocalFile() lines 1030 .. 1060. 
Since the re-opening wasn't broken and closing a non-opened file does not hurt 
it still worked.

-- 


Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
The gates in my computer are AND,OR and NOT, not Bill
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20091010/39b57d9d/attachment.sig