File not found

I’ve been transferring a large directory (approx. 22GB) from my RISC OS Pi4 to a RPCEmu installation on a Windows laptop, using LanMan98 as the intermediary. In the course of copying the data across I regularly encounter an error message from Filer: ‘File not found’, and the options of Retrying, Restarting, Skipping or Aborting the copy. Selecting either of the first two has no effect, so I select ‘Skip’ and the process continues until the next instance. I should add that the Filecore-formatted SSD disk holding the original data has been checked by Disknight and found to be free of defects. I should further add, that every large-scale copying exercise I have done, on RO devices ranging from a RiscPC running 4.02 to an Iyonix to all generations of Pi from 1 to 4 have encountered the same problem. However, if I go into the donor hard disk and locate the file, it can invariably be opened.

So what is going on here?

The problem with this behaviour of course is that no large-scale copying operation can be left to run unattended, becuase sooner or later it comes to a halt with the aforementioned error. If it were possible to parse the directory before launching the copying operation and locate the dodgy files, that would be hugely useful, but I know of no way to do this.

That sounds really annoying :-C
Just throwing this out there but is there anything unusual about the filenames e.g. special characters or a dot for hidden files or something like that?

Is it a case where there’s a file and directory with the same name, or maybe the same filename with different filetypes?

Grahame might have a point. Is this one of those old 8.3 names issues I wonder?

It’s probably character translation. When using foreign filing system you should not use top bit or most punctuation characters, as they will cause problems. Stick to letters, numbers, pling, underscore, dash and forward slash.

The filer creates a file then tries to open it to copy data across, but Lanman98 (and others such as LanmanFS and to lesser extent Sunfish) don’t have a proper bi-directional mapping for all characters, so fail to find what has just been made. I had to rename an awful lot of stuff (or put in archives) before I could back up all my RISC OS files on to a NAS.

The error message helpfully does not quote the name of the file it is trying to find otherwise a *spool fred / *spool would create a list of the errant files.

This reminds me of the intelligence shown by DOS to the command

C>format

Is it possible to intercept the ‘open’ command so that a different error message (or log) is created that includes the full canonicalised file and path name it is trying to open if the open request returns zero? That would be an extremeny useful thing to have.

It’s probably character translation.

On further investigation, I think that is precisely the problem, and not of the Filer per se, but of LanMan98. Problematic characters I have found are Alt 151 and Alt 255 (can’t reproduce them here, but the former is an elongated dash and the latter is a y with umlaut, typically inserted by Windows in any RO filename with blank spaces between the constituent words}.

LanMan98 permits copying such a file from a Filecore-format harddrive to a Hostfs drive on the PC, but if you then attempt to delete the file or shift-drag it back to its original place, you get ‘File not found’! Hey ho.

There’s also a converse situation which can result in two different files with identical names. I can’t remember exactly how that happens though. I think it is when you view the Windows directory from RISC OS after some copying takes place.

Its when you have files which only differ by the DOS or filetype extension.

e.g. file.txt file.doc file,fff

You will see them in the filer, but any access will only be to one of them.

In reply to David “It’s probably character translation. When using foreign filing system you should not use top bit or most punctuation characters, as they will cause problems. Stick to letters, numbers, pling, underscore, dash and forward slash.”
That surely works in counties where the standard language has no such characters – for me where German Umlauts are normal characters expecting me to avoid them in file names ist not really a useful option.

That character translation can be an issue is accepted and LanMan98 does have this issue if the opposite side is Windows 11 but if the share is on my NAS the problem is not there. So for now I use the NAS as shared space – works but is a drag.

LanManFS does not have this translation issue but is pretty useless since a normal safe Windows 11 has more than one IP address (due to some HyperV instance for security features) and LanManFS like LanMan98 fails to connect since it uses the wrong IP; LanMan98 allows me to specify the IP address, LanManFS unfortunately does not.

Overall the real solution would be a decent SMB client filing system to replace the outdated LanManFS and LanMan98 that still use NetBIOS name resolution (but not properly) and SMBv1 (insecure).

Could you have a separate prog that could run through all the files on HDs to point out any possible probs.

Similar problems exist to some extent in the various HostFS implementations, usually because no one has thought about the corner cases and there isn’t a defined heuristic that round-trips 100%.

File extensions should only be stripped when there is no ambiguity in the remote directory, else they must be retained. This is a common problem.

As for repertoire, we have enough difficulty in RISC OS with <60> and undefined numbers of GSTrans so a more stable way of escaping difficult characters should be chosen – it’s a pity we can’t allow %XX or &ent; for hysterical raisins (even though they’d be unambiguous).

Could you have a separate prog that could run through all the files on HDs to point out any possible probs.

That would be extremely useful. It would (a) enable correction of potentially troublesome file names, or (b) give the option of removing said files from a directory due to be copied, thus allowing the copying process to continue without interruption. I’ve been using RISC OS daily for thirty years or thereabouts, and have accumulated a large number of legacy files, a number of which have problematic filenames. I wouldn’t be surprised if this was fairly typical of current users.

The problem is, every foreign network or disc filing system has a different set of characters which cause problems. In the past I’ve used Lanman98, LamanFS, SunFish, and a couple of flavours of emulator HostFS, some characters work on one and not another, hence my rather generic advice.

The way I found out what worked and what didn’t each time was to use !DirSync to do the copying. Because it supports incremental backup (copying only what has changed) once it has copied all the files, it goes back and checks each one is now the same on the destination. If there are any naming issues, it will show unmatched files in the source and destination.

!DirSync will also pick up lack of support for untyped files on most (all?) foreign filing systems, as the timestamp on the destination will either be in distant past or far future. If you need to preserve the old load/exec addresses for BBC Micro stuff, you need to put them in a Spark archive.