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

List:       kde-core-devel
Subject:    Re: [PATCH] KConfigBackend
From:       ossi () mail ! kde ! org
Date:       2002-02-26 8:10:15
[Download RAW message or body]

>    enum { PreserveMode, PreserveLinks, PreserveOwner, NoUmask };
>
uhmm - shouldn't the values be explicitly assigned = 1, = 2, = 4, etc.?

>     * @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.
... or the current user is root.

>     * @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.
this function needn't to be dangerous. we needn't to open the link. we
could do readlink (until it fails!) on the file and then operate on the
link target. _then_ the problems begin, but that's only related to
ownership.

>     * @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.
... but only, if the current user is not root. chown is your friend.
also, this options is obviously irrelevant, if the file is owned by you
anyway.

>     * @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?
>
yes. you want it, you get it. :)

> What should happen with PreserveOwner without PreserveMode?
> 
for root this obviuosly works (and these two options are mostly relevant
only for root). when the file is owned by us already, the PreserveOwner
stuff is irrelevant, to.
for the remaining cases we obviously need some more options: 

* TryHarder: if not set, the function will fail with errno=EACCESS in a
case where it cannot satisfy the request. if set, another option is
examined:
* Unsafe: if set, overwriting the existing file is allowed at the cost,
that the operation is not atomic. that would help for the PreserveOwner
case, but not for the !PreserveMode case.
if not set, it will try to satisfy the mode setting at the cost, the symlink 
is possibly removed and/or the ownership is changed.

i'm not sure about the defaults for kconfig.

greetings

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