[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] KConfigBackend
From:       Waldo Bastian <bastian () kde ! org>
Date:       2002-02-26 6:32:34
[Download RAW message or body]

On Monday 25 February 2002 02:25 pm, Hans Meine wrote:
> Waldo Bastian <bastian@kde.org> writes:
> > > b) i don't like the ksavefile vs. fopen code. i'm in favour of moving
> > > this whole discrimination to ksavefile (and obviously adding some more
> > > options to it).
> >
> > That breaks the semantics of KSaveFile. In order for abort to work you
> > must create a new file.
>
> What about (for KSaveFile)
[Snip]

That might work. Instead of renaming the file in close() we would then need to 
copy the file.

To accomodate that in KSaveFile I came up with the following interface:

   enum { PreserveMode, PreserveLinks, PreserveOwner, NoUmask };
   /**
    * @li PreserveMode - When this option is set, the file mode of the
    * file will get the mode of the existing file iff a file or symlink
    * with the name @p filename is already present and is owned by the
    * current user.
    * @li PreserveLink - When this option is set, the data is written
    * to the symlink iff a symlink with the name @p filename is present.
    * Without this option the symlink would be replaced by a new file.
    * This option may corrupt data when the program is aborted while
    * writing to the symlink.
    * @li PreserveOwner - When this option is set, the data is written
    * to the existing file iff a file name @p filename is present and
    * is owned by another user.
    * Without this option the exisiting file is replaced by a new file
    * owned by the current user.
    * This option may corrupt data when the program is
    * aborted while writing to the file.
    * @li NoUmask - When this option is set, the current @ref umask
    * setting is ignored when setting the mode.
   KSaveFile(const QString &filename, int mode = 0666, int options = 0 );

Current behaviour is:
	options = 0.
The new KConfig behaviour would then be:
	options = PreserveMode | PreserveLink | PreserveOwner;

I am not quite convinced what should happen when PreserveLink is present but
PreserveMode is not, should the mode of the file pointed to by the symlink be 
reset? What should happen with PreserveOwner without PreserveMode?

The KConfigBackend interface would then become

KConfigBackEnd::setFileWriteMode(int mode = 0600, int options = PreserveMode | 
PreserveLink | PreserveOwner);

Cheers,
Waldo
-- 
Advanced technology only happens when people take a basic idea and add to it.
 -- Bob Bemer

[prev in list] [next in list] [prev in thread] [next in thread]