PATCH: Bug 73440: Konq deletes files when dragging

[Dawit A.]

On Monday 08 March 2004 03:24, David Faure wrote:
> On Tuesday 09 March 2004 14:54, Andras Mantia wrote:
> > On Sunday 07 March 2004 23:52, David Faure wrote:
> > > I think there is some confusion here.
> > > Overwriting a file by dropping another file on top of it in Konqueror,
> > > and writing to a file from within an application, are two very
> > > different things.
> >
> > Why should be different? Both can be triggered by the user, and I don't
> > see the difference between overwriting a file (symlink) in Konqueror or
> > saving a document  to an existing file (symlink) in a text editor.
>
> Because dropping icon A over icon B usually replaces icon B with icon A
> once you choose overwrite. The fact that icon B is a symlink shouldn't
> change this principle IMHO - but I also agree with the "ask the user"
> solution, if some people really need the feature to update the file behind
> the symlink's target (it would be good to have some input from people
> actually doing this; I use symlinks to both files and dirs, but I never
> drop something onto a symlink to a file...).

Well I think I might have changed my mind on this ;) In the absence of any 
clear standard on an issue I think we should default to the "defacto" way of 
doing things. And in this case in unix the destination of the symlink is the 
one that gets changed on such actions. This makes us consistent with all the 
other non-KDE tools. However, I think asking the user is indeed a viable 
solution if it can be done easily.

> KateBuffer::saveFile uses QFile and KParts::ReadWritePart::saveToURL
> does nothing else in case of a local file (and uses KIO::file_move for
> remote files, but that should be fine too).
>
> This really makes me wonder, why apps would use KIO::copy/move
> (in particular for a single file)... What is kompare doing exactly?

Probably using KIO::copy/move with the overwrite flag set...

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"