"Filer" silently overwrite/replace existing files.

[Giova84]

"Filer" silently overwrite/replace existing files.

[humdingerb]

In case of conflicting filenames, we have these options:

• Overwrite existing file
• Rename the new file
• Don't process the file
• Ask the user
  The behaviour should be defined as part of every rule that deals with copy/move/rename with a section "Behaviour for conflicting files:" with a radio list of the above options.

In case of "Ask the user", a window will pop up.
Ideally, it should show info on the old and new file side-by-side (e.g. icon (double-click could open the file), filename, mime type, size, last modified) and these radio options:

• Overwrite existing
• Rename new file to
• Don't process the file
  and a checkmark
• Use this choice for all files in this batch

The checkmark avoids having the window pop up again and again, and remembers the choice for all the files in the current batch of files.

Implementing a solution can be a bit complicated. Filer and AutoFiler may have to process many files in a batch. Filer is then invoked on each file in that batch. We have to keep that in mind when we "use this choice for all files in this batch".

[owenca]

Filer launches another Filer:
https://github.com/HaikuArchives/Filer/blob/master/sources/DropZoneTab.cpp#L155
https://github.com/HaikuArchives/Filer/blob/master/sources/FilerDefs.h#L12

This prevents me from creating a modal popup window from within the launched Filer although BAlert sort of works. (The alert is not modal relative to the Filer tabs window.) Is there anything to do about this problem?

[humdingerb]

Yes, if I see this right, dropped files are fed serially to a newly created, then destroyed Filer instance. A popped up dialog will block only that affected Filer instance, thereby blocking the processing of the following files of the drop. It wouldn't block the Filer main window, and why would it.

Question is, how to deal with that checkmark that will have to chosen action remembered for all files of this one drop? I alluded to that in the last paragraphs of my initial comment to this ticket. Not sure how to solve it... maybe some communication with the "main app"? But how to deal with a bunch of files being opened with Filer via "Open with..." in Tracker?

[pulkomandy]

@owenca
Ok, here is what happens:

1. Filer creates a new application
2. That new application creates a window, but its main thread continues running
3. The operation isn't stopped, it terminates
4. The app exits, the window is destroyed.

With a BAlert, you can use synchronous mode, which blocks the calling thread completely, so it sort of works, but it is probably not a good idea.

On modal windows: there is no need for that here. The main window should remain working and you can start other copy operations while the particular one having a conflict is waiting. I suggest reading the HIG on modal windows, basically, they should be avoided as much as possible.

So, what to do:

1. Filer starts a new app
2. The app creates and shows the window
3. The app does not proceed with moving the files, and stays idle
4. User replies in the window and closes it, reply gets to app
5. App resumes copying files, acting upon reception of the reply

That should work. Wether re-starting the app is really needed should be reconsidered however, as humdinger said, it creates some complications when trying to make a remembered setting apply live.

[owenca]

Thanks! I had already created a BAlert-like modeless window that would stay on the screen until an action button is pressed, using a semaphore. (I confused modal window with having the window stay on the screen.) I will learn to do it the way in "what to do" 3-5 above when I am done.

I decided that it would be better not mixing renaming with move/copy after analyzing the existing code. So I use two action buttons (Overwrite and Skip) along with a checkbox "Don't ask again" in the popup dialog. If the user wants to rename conflicting files, he can always click on the checkbox and press Skip and then run a Rename rule.

MoveAction() and CopyAction() in RuleRunner.cpp are almost identical except for two places (calling MoveFile() vs CopyFile() and printing "Moved" vs "Copied"), so I refactored the code and added the logic to handle "Don't ask again". I will create a PR shortly.

I scanned through the HIG. It has lots of good design tips!

[humdingerb]

If the user wants to rename conflicting files, he can always click on the checkbox and press Skip and then run a Rename rule.

Is that a good idea? It sure would be more convenient to have only one rule that copies a file somewhere and have Filer deal with possible renaming when there are conflicts. Otherwise the user has to come up with a quite a bit more complicated rule that deals with renaming+copying. And he has to invoke two runs instead of one.

[owenca]

I feel that letting the user rename the files while moving/copying would make things overly complicated. I thought about giving him two options: rename the existing file by appending .old or rename the new file by appending .new. Then I would have to check if the .old or .new file already exists. Another possibility is to append "(1)", "(2)", etc. I just don't feel very confident about all this.

[owenca]

Here is the PR: #16

[humdingerb]

Yeah, I know it's complicated. :)
Would be much easier if somehow Filer could used Tracker's functionality of auto-renaming (adding (1), (2),...).
I'd say this is one big step in the right direction.

[Giova84]

Hi Humdinger, I've seen that you committed the fix from owenca, 11 days ago:
f7cd9b6

So, this ticket can be closed? I've built Filer from the last source and seems to work ok.

[humdingerb]

Yep.
@owenca: feel free to create new issues for the things still missing, even if you yourself won't work on it (immediately). Like the optics of the conflict window etc.

[owenca]

Will do.