Trap Filer Overwrites

This topic has been imported from the old forum. Due to its use of fixed format text, you may need to make your browser view wider in order to see posts with the correct layout.

In the case of copying things with the Filer, you’ve already got an option to do that.

Really? How? I always missed that on RISC OS. It was certainly not possible to configure it in !Configure. There are some options there to alter confirmation options, but IIRC none that result in confirmation for overwrites only.

Open a menu in a filer window and follow “Options”. Untick the “Force” option and the filer will prompt for confirmation of actions like deleting (within the filer) and overwriting files (from the filer to another filer window).

If you run !Configure’s Filer plug-in, you just untick the “Force” option. This will cause that to be the default state every time you boot.

Yes, I know that, but what I want is confirmation of overwrites only. I don’t want to confirm every file I chose to delete. When I delete files, I usually mean it. And if I did it accidentally, I can recover them from the bin. But if I drop one directory structure onto another (to merge them) I would like to be asked what to do for every file that would be overwritten.

Ah, I see. Sorry, I wasn’t clear that you were making that distinction. Well, the Filer sources have been released… ;-)

Well, the Filer sources have been released…

That’s going to be of limited use though, since the functionality is in Filer_Action!

That’s going to be of limited use though, since the functionality is in Filer_Action!

Meh. Everyone’s a critic.

Prrp. :-P

SR wrote:

From the operating system’s point of view, it cannot do anything to change this because although it is technically possible to spot when someone is trying to write to a file you do not know if that is the first time that they have tried to write to that location /and/ the file was loaded from somewhere else or created afresh.

This is completely untrue of course. ;)

I wrote a sideways ROM for the Beeb sometime last century which did precisely this, and it can be done nicely under RO too.

A task filter monitors each task’s DataLoad and DataSave messaging and tracks loads and saves, caching canonicalised filenames. A DataSave message with a permanent destination that the task hasn’t previously accessed gets suppressed, and a confirmation window is opened. When the user confirms, the DataSave is resent.

This relies on the undocumented fact that you can delay the DataLoad/DataSave protocol for as long as you like (for some definitions of “as long as you like” – YMMV), for example to load or save in bits using GBPB and polling inbetween, so big file transfers don’t lock the desktop – I’ve used that technique before.

You’d also have to trap things like calls to OS_File when some app decides it wants to load the file for some other reason – like typing the filename into a window and clicking the “load” icon and later it tries to auto-save the file with another OS_File, or maybe by opening output to it and writing data then closing it, or maybe creating a temporary file and moving that over the top of the original, or maybe…

Apps don’t always load a file because it was double-clicked or dragged to the app and they certainly don’t always save files using the Wimp’s data transfer protocol.

You’d also have to trap… OS_File

Yes Steve. How do you think the Beeb version worked?

The point I neglected to spell out is that such an approach would obviously result in the whole desktop stopping OS_ReportError style – and we shouldn’t be encouraging that kind of thinking this century, fine as it was for the Beeb.

Setting a callback from within the vector allows the task to be zombied at that point, with an OverwriteProtect module task filter then handling Polls for the task until the confirmation dialog is dealt with.

I’ve used this approach before somewhere – any attempt to interact with (or redraw) a zombied window causes that window to be temporarily closed, and when the OverwriteProtect dialog is dealt with they call get reopened and the task either continues with its save, or appears to get a Locked error back from the vector (which also seems to take a VERY LONG TIME from its point of view).

If RO had a PM WIMP this would be trivial. :/

Setting a callback from within the vector allows the task to be zombied at that point, with an OverwriteProtect module task filter then handling Polls for the task until the confirmation dialog is dealt with.

Setting a callback from within the vector allows the task to be zombied at that point, with an OverwriteProtect module task filter then handling Polls for the task until the confirmation dialog is dealt with.

Interesting, this sort of thing has been mentioned on the forums before at http://www.riscosopen.co.uk/forum/forums/2/topics/45 and http://www.riscosopen.co.uk/forum/forums/2/topics/25

You don’t however say how your task deals with wimp messages when zombied. I can also foresee a situation where hiding a window causes the one beneath to be redrawn so it’s hidden as well and so on – so basically loads of your apps windows disappear all in one go!

My ‘solution’ (which I’ll freely admit I’ve never actually tried) is to open a multi-tasking error box initially, and if a wimp message is received to ‘fall back’ to the standard single tasking modal error box.

basically loads of your app’s windows disappear all in one go!

That’s exactly what could happen, yes! One has to keep a list of the windows’ handles to reopen, but that’s all. It’s ugly, but less so than single-tasking.

A more complex approach is to do what Niall Douglass’s Wimp2 did (or rather Andrew Tierney’s Wimp2Patch helper, probably) and queue, accumulate or ignore individual messages as appropriate. Redraws at least would be fairly cheap to deal with, though ugly. Most messages could be safely ignored except Quit.

To an extent, this is a problem that needs to be solved with all the other Wimp problems – preemption is less ugly if windows are drawn into their own surfaces (since exposure redraw can be done without the task) and this then allows alpha blending, hardware scaling and other post-processing to be employed (Beryl, anyone?).

However, back in the realm of What Will Get Done, as opposed to Could, I don’t think anyone should worry about what happens to a task’s messages whilst it is stuck at a modal (but MT) dialog – just look what happens under Windows – files don’t get launched, protocols pause silently… in other words, you can’t have it both ways.

if a wimp message is received to ‘fall back’ to the standard single tasking modal error box.

Sadly, messages are flying about all the time, or can be – don’t forget about broadcasts.

if a wimp message is received to ‘fall back’ to the standard single tasking modal error box.

Sadly, messages are flying about all the time, or can be – don’t forget about broadcasts.

I don’t quite understand what you mean. I haven’t tested what would happen if I called Wimp_ReportError after a User_MessageRecorded was received – would it be returned immediatley or could I deal with it after the return from Wimp_ReportError.

But all other messages should remain queued over a Wimp_ReportError and as multi-tasking stops no others should be generated.

3 months for a reply is a bit tardy, apologies.

Wimp_ReportError is currently entirely single-tasking – no other task gets a look-in.

If this was altered to have a form of proxied polling (by the Wimp on behalf of the task) it could allow another task (eg Filer) to broadcast a message that would either have to be ignored by the zombied task or queued, with unpleasant results in either circumstance.

DataRun is the killer – it would have been nice to register which filetypes a task was interested in, as a subclass of which messages, to avoid this very problem. Too late now. Anyway, there are other broadcasts with similar problems.

Currently, if Wimp_ReportError blocks the system, no programs can run. If Wimp_ReportError blocks only the task which generated the error that would be no problem. It’s the same with the blocking system. No messages would be send to the zombied task, only clicking the button’s would work. The + side is that the other task can continue to run.

Slowest conversation ever?

If Wimp_ReportError blocks only the task which generated the error that would be no problem.

I beg to differ. If it is Draw which generated the error, and is zombied at a MT ReportError, then the user could double-click another Draw file in a Filer window.

This gets broadcast… so as I said earlier, either the message would have to be queued (resulting in “nothing” appearing to happen, causing the user to double-click again probably), or the zombification causes the message to never get to Draw, causing another copy of Draw to start. If the message was something more crucial – a communication protocol between client and host for example – anything could happen.

As I said – it’s unpleasant either way.

Yes, it’s unpleasant either way. Lets split the problem:

1: double click a file. Blocking: you can’t. Zombied, an other application starts. For me, no problem.

2: communication between programs 2a: on the same computer Blocking: it is stopped an starts again. Zombied: problem for zombied program, not for other programs.

2b: between computers Blocking: all programs have problems. Zombied: for zombied program, bad. All other programs continue.

3: task under interrupts continue and want to communicate with a program. Blocked: problems. Zombied: only problems for zombied program.

All in all, I think zombification is the less worst solution.