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

List:       kde-devel
Subject:    Re: bug in moving/overwriting a FOLDER
From:       Christoph Wiesen <chris () deadhand ! com>
Date:       2004-11-19 11:05:21
Message-ID: 200411191205.21755.chris () deadhand ! com
[Download RAW message or body]

Am Friday, 19. November 2004 11:16 schrieb David Faure:
> On Friday 19 November 2004 11:02, Christoph Wiesen wrote:
> > Am Friday, 19. November 2004 10:43 schrieb David Faure:
> > > This discussion is amazing.
> > > You want to let the user overwrite a folder (full of subfolders and
> > > files) with one new empty folder (or even one file) ?
> > > How can you make KDE more dangerous than that?
> > > By pressing the wrong button, the user would lose an entire tree of
> > > folders? No thanks.
> >
> > Oh no, there's a misunderstanding here. What should happen is that the
> > folder that gets "overwritten" (wrong word actually) will contain BOTH
> > the files that have been there before and the files that came from the
> > overwriting, That's the way it always worked for me in KDE, and it would
> > be a real problem if that for some reason stopped working
>
> Ah, that kind of overwriting. Yes, of course.
> (BTW does someone know how Windows, or Mac, or Nautilus calls that
> operation?)
>
> Hmm, in fact calling it overwrite isn't too wrong: yes it's a kind of
> merging, but it will ALSO overwrite any existing file with the same name,
> in there.
> If you copy (or move) A/ into B/ and both A/file1 and B/A/file1 exist, then
> choosing to "overwrite B/A with A" will indeed overwrite B/A/file1 with
> A/file1.... So it's a "merge and overwrite"...
>
> So OK, we could offer overwrite, and then go to the "copy all source files
> one by one, then delete them" code. Remembering that we chose to overwrite
> the contents of the dir... I'll give that a try.

Yes that described exactly what is meant (at least by me) - and the problem 
about overwrite vs. merge is correct to.
Though - and that's where i'm not sure anymore - I really don't have any 
problems here. It works (and has at least in 3.3.x and I think in 3.2.x as 
well worked) for me just like that all the time. I am not using CVS, so if 
the original poster of this bug is correct - which I assume since so many 
people thing this actually _should_ not be possible - this would have been 
introduced into CVS after 3.3.

just to be 100% sure, here is exactly what I did jsut now to verify the 
current (and imo correct) behaviour:

(Everything has been done through Konqueror)

Create a folder under /home/chris named "testfolder" and created the some 
contents:
- testfile_A1 (Empty "Plain Text Document")
- testfile_A2 (Empty "Plain Text Document")
- testfile_A3 (Empty "Plain Text Document")
- testfile_to_be_overwritten ("Plain Text Document" with the content: "this is 
the file from "test-folder"")

Then I created another "testfolder" under /home/chris/temp/ with:
- testfile_B1 (Empty "Plain Text Document")
- testfile_B2 (Empty "Plain Text Document")
- testfile_B3 (Empty "Plain Text Document")
- testfile_to_be_overwritten ("Plain Text Document" with the content: "HEY, 
THIS IS ANOTHER TESTFILE!!")


So obviously what I'm going to do now is "overwrite" /home/chris/testfolder 
with /home/chris/temp/testfolder. I can do this both with cut'n'paste as well 
as via drag and drop -> "Move Here".

I chose cut and paste and get the dialog box as shown in the attached 
move_test.png. As you can see I have the option overwrite. I chose it.

(Just for the record: If I do this same operation with copy instead of 
cut/move I get the options shown in copy_test.png (attached).)

All in all I end up with this:

/home/chris/testfolder
- testfile_A1 (Empty "Plain Text Document")
- testfile_A2 (Empty "Plain Text Document")
- testfile_A3 (Empty "Plain Text Document")
- testfile_B1 (Empty "Plain Text Document")
- testfile_B2 (Empty "Plain Text Document")
- testfile_B3 (Empty "Plain Text Document")
- testfile_to_be_overwritten ("Plain Text Document" with the content: "HEY, 
THIS IS ANOTHER TESTFILE!!")


This is as far as I'm concerend the correct behaviour. Windows Explorer does 
the same - maybe not exactly - can't test this here - but it's definitely the 
same logical approach, where the contents gets "merged".


Still I think as it is now the description "overwrite" for this kind of move 
command is correct, since there has be no further question to overwrite the 
file "testfile_to_be_overwritten". notice that it got overwritten without 
(additional) 'ok' from the user.


If that's what doesn't work anymore I think we have a problem. Other issues 
(as it is for me here now) are:
- Less options / meta information within the move dialog compared to the copy 
dialog.
- No destinction between 'overwriting' ('merging') the folder and overwriting 
files that are within this folder. If there is NO change it's ok, since the 
user said to "overwrite" already. If there will be change to differentiate 
between those to tasks then there should be the "obverwrite all" and 
"autoskip" options inside the move-dialog since it will ask about every 
single file (that could be overwritten) again otherwise. 


I really hope this was not confusing and could help to clear up the situation. 
All this has been done under Debian unstable with the Debian Unstable builds 
of KDE 3.3.0a-1 (that's the version of kdebase) .


Sorry if I confused someone even more :-(


*"Attached" files are here instead:
http://www.deadhand.com/kde-debian/move_test.png
http://www.deadhand.com/kde-debian/copy_test.png
(Message was to big to be posted on the list | >50KB)
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]