ChangeFSI broken

Probably caused by not specifying the recurse flag when calling xosfscontrol_copy in Unbin(), so this could be an easy fix.

If only all bug reports were as succinct and direct as that, life would be a breeze 8)

GIGO is one of the options I’m considering (commute FilerAction deletes to DataLoad messages)

Do you mean you would be using GIGO as the bin, rather than adding bin capability to Transient?

If only all bug reports were as succinct and direct as that, life would be a breeze 8)

So it’s fixed then. :-)

Do you mean you would be using GIGO as the bin, rather than adding bin capability to Transient?

As said it’s still early days and I’m still considering different scenarios. Ideally I’d like to be able to trap all deletions but that will require a different technique from what TrapDelete is using.

Currently TrapDelete only works on deletions via FilerAction, commuting the Delete action to Move (by Copy & Delete so it works across different FSs). This could be changed to keeping track of Message_FilerSelectionDirectory and Message_FilerAddSelection so it knows which objects will be acted upon.

When it spots Message_FilerAction 2 (Delete) it could stop the message from being sent to FilerAction and instead send a Message_DataLoad for each object to another task. That task could be anything, BlackHole, GIGO, Transient, etc.

To the receiving task it would be if the objects were dragged to its iconbar icon (assuming they don’t check if the messages come from the Filer) and would move them to their ‘bin’.

Well that’s the plan, just need to write the code to see if it actually works.

Currently TrapDelete only works on deletions via FilerAction, commuting the Delete action to Move (by Copy & Delete so it works across different FSs).

A ‘copy and move’ on the same drive is going to be vastly slower than a rename. Could you check if it is on the same drive and if so use rename

A ‘copy and move’ on the same drive is going to be vastly slower than a rename. Could you check if it is on the same drive and if so use rename.

I think the first version was intended largely as a proof of concept for the structure retention.
First make things work then improve the performance.

I think the first version was intended largely as a proof of concept for the structure retention.
First make things work then improve the performance.

Steve is spot on here.

The current incarnation no longer alters the FilerAction reason code it now blocks Delete and sends DataLoad messages to a specific target app instead.

This is working with Transient (after a few tweaks) and GIGO, BlackHole is proving difficult. The advantage of this method is that both apps prevent files with the same leafname from being overwritten. In GIGO’s case you can put an object back to its original location too.

Next step is to extend this, it currently only works for the first object in a selection, but that should be quite easy. Then decide how to further integrate this with Transient – possibly by pinching a large chunk of GIGO’s functionality.

Sorry if I jumped the gun. Sounds promising!

This is working with Transient (after a few tweaks) and GIGO, BlackHole is proving difficult. The advantage of this method is that both apps prevent files with the same leafname from being overwritten. In GIGO’s case you can put an object back to its original location too.

I don’t think Blackhole is worth major effort. There are too many quirks/issues:

1. Unless people have a copy of the Foundation Risc User CD they won’t have the 32 bit version of the module.¹
2. If they have current board machine they won’t have ADFS and the !RunImage file needs modification so that it doesn’t fall over on not finding the ADFS SWIs
3. The screen savers need an update of the support module.² I suspect if people really want animated screen savers they will pull out the appropriate element and modify it for use on new machines.
4. Other features bulk out the overall package but are possibly of less use to people.

For me Blackhole serves a single purpose – file protection/recovery

Edit
¹ Amateur hackers aside
² If you dig a little you can find the module, but it’s a search exercise

Sorry if I jumped the gun. Sounds promising!

No problem. In fact, it’s caused me to look at FilerAction more closely and I could have just used Rename as it will fall back automatically to Copy & Delete if that fails.

I don’t think Blackhole is worth major effort. There are too many quirks/issues:

You may well be right. As sending a DataLoad is essentially the same as dragging to an iconbar icon I felt it was worth a try. If it worked users would be able to pick the bin application they preferred. The issues I’ve found with this, as well as those you’ve listed, make it more difficult to produce a version that works properly on RO 5. Even if we could, there’d still be the question of distribution rights.

For me Blackhole serves a single purpose – file protection/recovery

So, Transient + TrapDelete and a 32-bit nOver would be a viable alternative?

So, Transient + TrapDelete and a 32-bit nOver would be a viable alternative?

You seem to be working on a restore function as well so it’s a true recycle bin don’t you think?

Transient for the repository is partway there, the Gigo feature with a number suffix for duplicate copies is a more finished item. What Gigo has been missing is a filer delete capture. Missing from both is an optional notification of a delete action and a visible notification of “fullness” in the repository. I know of nothing that could restore the file or application to its original location.

Combine in one application and you could call it “Recyclin” (a sort of colloquial pronunciation of recycling). One of those three green arrows in a triangular loop logos for the icon?

To answer the question – yes a viable alternative.

You seem to be working on a restore function as well so it’s a true recycle bin don’t you think?

Yes, I’m looking at this. The initial implementation will probably be very similar to Gigo.

Transient for the repository is partway there, the Gigo feature with a number suffix for duplicate copies is a more finished item.

In what way is Gigo’s feature more finished, given that Transient does similar?

Missing from both is an optional notification of a delete action

Transient can be set to open the target directory, does that count?

and a visible notification of “fullness” in the repository.

Would that be for the ‘Bin’ part only? Remember that Transient can have other objects in it that didn’t get there through deletion.

To answer the question – yes a viable alternative.

Well, I have some ideas of how to integrate overwrites too, but only with Transient. That would make Transient handle most objects that you want to hang onto for a short while before discarding them permanently.

I have updated the TrapDelete download to the latest version. It now sends DataLoad messages to the target application allowing it to rename duplicate copies.

The download also has a required update for Transient, and a tip on how to filter deleted objects to a specific user.

In what way is Gigo’s feature more finished, given that Transient does similar?

I hadn’t noted that, probably the low use of Transient due to its lack of delete intercept. Silly mistake on my part.

Transient can be set to open the target directory, does that count?

The notification in Blackhole is a timed popup message, I’m personally ambivalent about it but others may like it more.

Would that be for the ‘Bin’ part only? Remember that Transient can have other objects in it that didn’t get there through deletion.

As can both Gigo and Blackhole. Only Blackhole produces a permanent notification of content in the bin.

The auto expire of Transient makes it an auto emptying bin. When the content is deliberately put there notification of fullness might not be a requirement, when the content arrived by result of a delete or an overwrite a notification is needed.

Well, I have some ideas of how to integrate overwrites too, but only with Transient.

I think that’s the point at which you need the exclusion list for paths that you don’t want monitored, otherwise a complicated compile could be a bit irritating – saving the temp files etc.

I have updated the TrapDelete download to the latest version. It now sends DataLoad messages to the target application allowing it to rename duplicate copies.
The download also has a required update for Transient, and a tip on how to filter deleted objects to a specific user.

I’ll give it a run for a while. Blackhole is out of the way now.

BTW. Looking forward to checking the restore function.

I’ll give it a run for a while.

So far so good. I’ve dropped it in the boot sequence of the RPCEmu instance to be run just after Transient.
Not on the beagle as yet.

Is it tested on 26 bit systems at all?

Have tried using the latest ‘TrapDelete’ with GIGO. I have now realised there is a bit of a gotcha with GIGO.

I used SyncDiscs to sync a few of my programming project directories between my Iyo and PandaBoard.

GIGO started throwing up a string of warning messages (Gigo is still waiting for other files to be moved to the bin). On checking GIGO’s source, it is currently limited to handling one filer_action at a time. If another delete occurs before the one it is handling is finished, it puts up the error and ignores the new delete. One then ends up with only some of the deleted files appearing in the bin.

SyncDiscs can be set up (user option) to spawn multiple filer_actions while syncing a directory- thus GIGO may get ‘overwhelmed’ with a string of deletions (spoofed as drags to iconbar by TrapDelete).

It is possible to start several filer_actions (deletions) manually of course, by dragging to the GIGO icon, and if doing that the same problem would occur.

@Fred: Are you intending continuing with support for GIGO as well as Transient as a bin application? If you are not, then I won’t bother trying to do anything with GIGO to allow it to handle multiple filer_actions.

The notification in Blackhole is a timed popup message, I’m personally ambivalent about it but others may like it more.

Adding a timed popup message and making it optional should easy enough.

BTW. Looking forward to checking the restore function.

I’m inching towards it. Transient now uses the SlidingHeap module for its memory management. Previously it only needed to store its expiry list but now the restore data must be stored as well.

Also added a Restore window (similar to GIGO’s) and made it open when you drag an object from inside Transient’s temp dir to its iconbar-icon. Next is to work out the format of the restore data, and display it in the restore window.

SyncDiscs can be set up (user option) to spawn multiple filer_actions while syncing a directory- thus GIGO may get ‘overwhelmed’ with a string of deletions (spoofed as drags to iconbar by TrapDelete).

TrapDelete can’t handle multiple Filer Actions either, if they were to send messages simultaneously, as it only has one dynamic area to store the object names.

Looks like I need to change, again, how deletions are trapped but if what I have in mind now pans out, overwrites would be catered for too. :-)

BTW it’s very useful that SyncDiscs can spawn multiple Filer Actions, that’ll make a good stress test for TrapDelete once it out of the design stage.

@Fred: Are you intending continuing with support for GIGO as well as Transient as a bin application?

If possible, ie not too much effort, then yes. I’d suggest waiting tough until TrapDelete’s implementation is largely set so that an assessment can be made on what changes would be required to make GIGO work with TrapDelete.

In view of the progress made since I offered to try to contact Mark Greenwood, the author of BlackHole, this is probably now completely redundant but I’ll report back anyway:

My email to Mr Greenwood didn’t bounce but nor did it elicit a reply so I have no way of knowing if it actually reached him; perhaps it disappeared into a black hole? :-)

Last week-end I emailed Bent Bracke to see if he could help in contacting Mr Greenwood but so far no response there either (in fairness Bent Bracke may still be trying to contact Mark Greenwood on my behalf).

Finally, I looked on Facebook; I had no idea what a popular name Mark Greenwood is worldwide – there are dozens and dozens, if not hundreds, of Mark Greenwoods out there and from what I’ve seen there’s not enough information given to provide much of a clue as to which, if any, might be ‘our’ Mark Greenwood. Doing an internet search was no better. Needle in a haystack job, for which I’m afraid I don’t have any further time.

Having said all that, the progress being made by Fred et al is most encouraging (I’ll try to refrain from any puns about filling a hole (black or otherwise)).

Linkedin can be a good way of tracking people down.
Do you what part of country he is/was in?

Having said all that, the progress being made by Fred et al is most encouraging

That needs a full stop after Fred I think, although if Chris amends anything in Gigo I’m sure he’d appreciate a thank you or two.

Having had TrapDelete running as an extension to GIGO 24/7 for four days, it seems to be working without problems. As transient is running as well, stuff expired by Transient gets trapped in GIGO, which might not be what one wants. However, since the final mode of operation of the filer trapping is not fixed yet, that is something that could be addressed later.

Have now changed TrapDelete over to send deletes to a Bin user in Transient. Manual testing looks fine, so we wait to see what happens overnight when SyncDiscs runs a range of backup jobs.

As mentioned previously I currently have both Transient and TrapDelete starting as consecutive items in the Run at boot.
Having left Transient/TrapDelete running across a midnight boundary without issue, I have also made sure of a new boot for the day scenario.

This morning gave me a filename not recognised error looking for “$.Boot.Resources.!Scrap.ScrapDirs.ScrapDir.Transient.Default.” this seems to be missing the Transient$TodayLeaf element of the name. This was reproducible with cold or warm reboots.
Introducing another item between Transient and the TrapDelete startup cured the problem.
Then removing the item between the two the error still does not occur.

Needs more testing but I think it’s a race condition with TrapDelete startup trying to run before the Transient$TodayLeaf name is available to the system.

Thanks for testing TrapDelete guys!

Don’t over do it though as the latest version differs quite a bit from the last release. It no longer sends DataLoad messages but instead changes the Delete action to a Move action (like the first version).

TrapDelete now assigns a serial number to each Filer_action task and moves all objects belonging to a delete task to a subdirectory with the associated serial number, The subdirectory is located in a special directory ‘Deletions’ in Transient.

When the Filer_action task finishes a DataLoad is sent to Transient which then moves the objects to its TempDir one at a time so that they can filtered to the various users.

The DataLoad message is doctored a bit, the estimated size is actually the serial number and the filename is the name of the directory from where the objects came. These are used to construct the restore information.

There are a couple of reasons for doing it this way

• The Filer_action runs normally, apart from the action being changed. This may be important for applications that monitor the Filer_actions they launch.

• TrapDelete gets a bit simpler as it doesn’t have to copy all the object leafnames and send a DataLoad for each of them to the target application.

• Each Filer_action has its own associated data so with multiple copies running TrapDelete is able to track each one separately.

• It will allow trapping of overwrites which have to be dealt with immediately or the file may get overwritten before it can be copied to safety.

Downsides are that each object has to be moved twice (but at least the second one is always a rename) and that it is currently incompatible with GIGO.

Transient has been updated to handle the above and it seems to work OK. A notification is put up when deleted objects are trapped and objects can be restored to their original location (although this is still very primitive).

Needs more testing but I think it’s a race condition with TrapDelete startup trying to run before the Transient$TodayLeaf name is available to the system.

Thanks Steve. I haven’t tested running Transient/TrapDelete at boot yet but will do so shortly.

Was that with the latest release of TrapDelete? Was Expiry turned on? If so, what happens if you turn it off?

Was that with the latest release of TrapDelete? Was Expiry turned on?

TrapDelete module v0.03 June 08. Expiry setting at default.

Irritatingly, despite having moved the TrapDelete load back to immediately after Transient in the boot I can’t repeat the error. I will try in the morning to see what a clean boot without a new day directory in Transient produces.

If so, what happens if you turn it off?

If I can reliable produce the error with expiry at default I will try with it off.

Busy weekend ahead with a friends wedding…

Irritatingly, despite having moved the TrapDelete load back to immediately after Transient in the boot I can’t repeat the error.

If the error is due to auto-expiry then only the first run on a day would produce the error, on subsequent runs there’s nothing to expire as it’s the age in days that counts and that hasn’t changed since the previous run.

If the error is due to auto-expiry then only the first run on a day would produce the error, on subsequent runs there’s nothing to expire as it’s the age in days that counts and that hasn’t changed since the previous run.

Ah, yes. One single run with no error would set things for that day hence the move back and forth thereafter is irrelevant, until the next day

Hmmm, not quite to simple – it’s past midnight and the TrapDelete startup is immediately after Transient – no error

I see you have made a lot of changes from the version of TrapDelete I have. One thing I was going to comment on (but may not now be relevant). Earlier today, after transferring some DSLR images using a card reader I deleted the images from the CF card (forgetting I had trapDelete/Transient set up). I thought the machine had stiffed as soon as the delete started. However, what had happened was that over 40 filer_actions had been started (one for each of the files in the original selection), copying the deleted images into Transient. It took quite a while with all the task switching and a slow card reader!

The Filer_action runs normally, apart from the action being changed. This may be important for applications that monitor the Filer_actions they launch.

That is very useful, since SyncDiscs, for one, keeps a track of each filer_action it starts, so it doesn’t have too many running at once (for the reason described above).

Anyway, Fred, I look forward to your next test version!

Why is a horizontal scroll bar appearing under each of my posts? Is everyone seeing it or is it something odd about my system?