File copy that logs errors and doesn't stop

What I’d like to see is a new “Copying files” window with a tick box that, when ticked, opens a new pane or area below and, when a file can’t be copied for any reason, the operation for that file is skipped and the information logged in the new area. Source file name, destination file name, and error message.

I’m trying to copy tens of thousands of files (yes, I know, it’s taking a long time), but I keep coming back to the monitor after a period away only to find that the copy process has stalled. Of course it continues after I click Skip, but what a waste of time – especially overnight. I bet that, just minutes after I go to bed, it will stall again, and waste the whole night. Just let the machine skip the file and tell me about it.

I would want to be able to export the log information from the area.

So how about something like the !NoError module which actually integrates with SysLog and responds to these Copy errors?

Not that I have the skills – just a suggestion of an approach for the (very much more) competent!

I bet that, just minutes after I go to bed, it will stall again, and waste the whole night.

Exactly so! I wholeheartedly support this wish.

Hmm. Could do with this for the Mac, too – no, I’m not thinking anyone here’s going to fix THAT for me! :)

If anyone does this, please make it sane and give up after ten sequential failures. No point logging failing to copy ten thousand files if Disc Full…
That said, when I have a lot of files to move, I stick them in an archive (compression disabled) and move that one file.

Great idea. Yes please.

Could you not check what the fault was? There’s a few cases (like Disc Full) that should cause it to stop, but there could be other things that might affect a block of consecutive files. One I had recently was a bunch where the pathnames were too long for the destination filesystem. There were more than ten of them, consecutive – but after I’d restarted beyond them it ran to the end. Not ten thousand files, mind.

I realised earlier today that there is a far easier implementation. When the box is ticked, just open a log file in Scrap, and extend the “Copying files” window to show an extra icon containing the name of the log file. When the log filename icon is double-clicked, open the file (in the user’s default text editor).

Much easier to programme.

And another thing really needs fixing: only a fraction of the longest filenames being copied is visible. You can’t see the root end of the path, and there’s NOTHING you can do about it, so you can’t go looking for what file it was that caused the copy operation to barf. Jeepers, guys, this is 2016 – we aren’t using floppy discs any more, we’re using hard drives with hundreds of thousands of files, some of which are deeply nested.

I would make the log file contain not just a list of the files that were not copied, but a series of *copy commands for each copy operation that failed so that you could run it as an Obey file so that it would (if you solved the issue) copy the files that were skipped. Then perhaps generate a smaller log file… Repeat as necessary.

You can’t see the root end of the path

What’s an easy way to implement this? The ways I can see include:

• Being able to slide the filename icon, or its contents, left and right – could be window scroll controls (though that seems OTT), or could be left and right arrows to slide sideways in chunks of 30 or so characters;
• The same effect as bubble help, i.e. hover over the icon and a bubble opens up with the full filename (which would have to wrap into a sensible width) but without turning bubble help on in general;
• Double-click the filename icon and a window opens up, probably a bit smaller than the Copying Files window, with the full text wrapped in there.

Better ideas welcome!

Make the field visualizing the pathname wrap and let the user choose the size of the filer action window?

I did a quick edit of the FilerAction template file to make the display icon larger and with validation L40, but this was not effective. I conclude that the app manipulates the icon flags, so no such easy solution appears possible.

I quite like the compactness of the window, so a fairly simple additon would be to just implement Help with the full filename.

The bubble help suggestion in that the file name expands when hovered over is already available via !FullNames by Andrew Booker and works well in my experience.

I did a quick edit of the FilerAction template file to make the display icon larger and with validation L40, but this was not effective.

Interesting as we’ve done that on RISC OS 3.7 and it worked for us!
I can’t recall what later OS versions we tried it on. I’ll check tomorrow if I have time.

I did make it work on the RO6 version, but with some problems, principally that the leafname is in separate icon to the pathname.

The RO5 version is quite a different beast, but maybe you can make it work.

Interesting as we’ve done that on RISC OS 3.7 and it worked for us!

We extended the window to show more of the pathname, but we didn’t change the validation to L40!

The bubble help suggestion in that the file name expands when hovered over is already available via !FullNames by Andrew Booker and works well in my experience.

I just tried it. Although a bubble appears over filenames that are truncated in a Filer window, it doesn’t appear over a truncated name in a Copying Files window.

It proves that the principle might work successfully, although I don’t know whether a full pathname would wrap, and it would at least look odd with a 230-ish character name if it didn’t wrap, and might defeat the object if used with a screen of insufficient width. But we don’t seem to have a ready-cooked solution.

Why don’t you play about with Fileract (castle.riscos.sources.desktop.fileract) I was in there recently to do with LanManFS it’s easy enough to softload with MkApp to compile it and test.TryApp to install it

As no-one else has, might I draw attention to this topic, when Rik Griffin was producing the current version in 2011:

https://www.riscosopen.co.uk/forum/forums/2/topics/636