Drag-N-Drop - Not drop target

[zer0]

If you're using WinRAR version 3.80+, I suggest you take a look at an option called "Wipe temporary files" in "Security/Miscellaneous". Or you can just set temporary files' path to a specific folder and include the delete command in your script to wipe contents as appropriate. There's always a way that doesn't involve pointing fingers

[nony]

Well i tried atleast 4-5 other FM's to confirm and everyone is able to do it.
Even Explorer does work properly So I doubt if other FM's doing something custom for WinRAR.
I wonder where XY is having problem. There could be so called workarounds but that would not be an effective solution provided by a FM itself. Also there are some other programs that don't work as expected in XY as said in some previous post. So the solution lies somewhere in XY, only it need to find it

[PeterH]

Did some test - maybe it brings some idea to Don?
Must test with IZArc, no WinRAR here...

While testing, I watch the temp folder used by IZArc with XY in active pane.
(Sometimes I must refresh manually - sometimes not!?)

- left-drag file from IZArc to XY (in 2nd pane) "copies" the file, but creates a copy in IZArc-temp.
- left-drag file from IZArc to WE copies the file, and even deletes the old copy in IZArc-temp!
- left-drag a duplicate to WE: you see file created in temp, and dialog asks "replace or cancel".
-- on replace it replaces, and the temp file is deleted
-- on cancel it terminates, but temp-file remains!
- left-drag a duplicate to XY:
-- "replace or cancel", and *after refresh* file is shown in temp,
-- after replace and after cancel the temp-file remains.

- right-drag to XY: "not allowed"!
- right drag to WE: temp-file appears, dialog "move or cancel"
-- on move it's moved, i.e. copied and deleted
-- on cancel it remains in temp!

From my point of view the dialog is misleading: I *copy* from IZArc to WE - and normally don't see that in the background a *move* from temp to WE takes place. But I don't know if the dialog is initiated from IZArc or from XY/WE. (IZArc should know better, XY/WE not.)

To summarize: XY never deletes temp, WE always deletes, *if* the operation is completed successfully.
The dialog on right-move (in WE) seems(!) to show that IZArc requests a move *Then* the temp should be deleted...

...and this would possibly explain, why WE does *not* delete, if the operation is canceled! (As no move takes place.)

[admin]

Did some test - maybe it brings some idea to Don?
Must test with IZArc, no WinRAR here...

While testing, I watch the temp folder used by IZArc with XY in active pane.
(Sometimes I must refresh manually - sometimes not!?)

- left-drag file from IZArc to XY (in 2nd pane) "copies" the file, but creates a copy in IZArc-temp.
- left-drag file from IZArc to WE copies the file, and even deletes the old copy in IZArc-temp!
- left-drag a duplicate to WE: you see file created in temp, and dialog asks "replace or cancel".
-- on replace it replaces, and the temp file is deleted
-- on cancel it terminates, but temp-file remains!
- left-drag a duplicate to XY:
-- "replace or cancel", and *after refresh* file is shown in temp,
-- after replace and after cancel the temp-file remains.

- right-drag to XY: "not allowed"!
- right drag to WE: temp-file appears, dialog "move or cancel"
-- on move it's moved, i.e. copied and deleted
-- on cancel it remains in temp!

From my point of view the dialog is misleading: I *copy* from IZArc to WE - and normally don't see that in the background a *move* from temp to WE takes place. But I don't know if the dialog is initiated from IZArc or from XY/WE. (IZArc should know better, XY/WE not.)

To summarize: XY never deletes temp, WE always deletes, *if* the operation is completed successfully.
The dialog on right-move (in WE) seems(!) to show that IZArc requests a move *Then* the temp should be deleted...

...and this would possibly explain, why WE does *not* delete, if the operation is canceled! (As no move takes place.)

Thanks for testing. I did a lot of testing as well over the years, and my current conclusions are:
- each archiver plays a little different; I tested 6 or 7 products in each one of them does it differently.
- the temp folders are most likely deleted by the archiver, not by the file manager. However, the file manager can somehow disturb this behavior, at least XY appears to do something wrong here.
- well, I don't know what I'm doing wrong.

[PeterH]

Sure I'm talking about *one* archiver, there can be differences...

I don't know about windows internals,and how XY is notified about the drag.
- If it's a move you have a problem, on not deleting.
- If it's not move you might have a problem on posting the operation (copy) as complete? (Only then the archiver could know *when* to delete the file(s).)

Seeing (if using WE) the temp file is *not* deleted on "cancel" of the move it seems to me, the "move in WE" deletes the temp? (And cannot do if canceled...)

And you don't allow (= handle?) right-drag, WE does.