Permissions when using file_move

[Andras Mantia]

On 2002. December 09., Monday 12:05, David Faure wrote:
> On Monday 09 December 2002 10:01, Andras Mantia wrote:
> > On 2002. December 08., Sunday 23:29, David Faure wrote:
> > [..]
> >
> > > Don't chmod an existing file in put()
> > >
> > > Ouch. Not sure anymore why I did that change (>1 year ago).
> > > Can't make up my mind on this. Anyone ? :)
> >
> > No idea, but if I specify the premission that I give, it should be used,
> > am I right? :-) If I want to get a file with the same attrs as src, I
> > just put -1 as permissions. At least this was my understanding.
>
> Wrong - if you want to get the same attributes as the source, you need to
> pass those attributes (how will put() guess them if you pass -1 to it ???).
> This is KIO::put(), not copy(), it doesn't know the source file.
>
> -1 means "use default permissions, those coming from the umask".

Ok, understood. -1 is default, does not come from the source. It's clear, but 
even in that case if the caller gives some permissions != -1 e.g in the 
file_move, then this should be taken in account, and the result (destination) 
file should have this permission.

> Permissions != -1 are usually those of the source file (e.g. when put()
> is called by FileCopyJob, called by CopyJob::copyNextFile).
>
> The analogy with command-line tools isn't as easy as looking at "cp -a"
> BTW. If you _edit_ an existing file (even as another user), it never
> changes its permissions. Isn't resuming a download in this case too? IMHO
> it shouldn't chmod the target. Maybe this is what the fix was about - not
> applying the permissions when resuming. Which still means they should be
> honoured when completely _overwriting_ the destination file. This would
> also be consistent with the KDE_open code above.

Yes, this make sense. Not honouring at all if the original exists (like it's 
in the old code) is quite bad. 

Andras