File not found
George T. Greenfield (154) 747 posts |
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. |
Julie Stamp (8365) 474 posts |
That sounds really annoying :-C |
Grahame Parish (436) 480 posts |
Is it a case where there’s a file and directory with the same name, or maybe the same filename with different filetypes? |
Steve Pampling (1551) 8154 posts |
Grahame might have a point. Is this one of those old 8.3 names issues I wonder? |
David J. Ruck (33) 1629 posts |
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. |
Chris Hall (132) 3554 posts |
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
it knows that it is a fixed disc and therefore does not need to prompt you to make sure it is the right disc (as it would do if you had typed ‘format a:’) so just says ‘press any key to format drive C:’. 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. |
George T. Greenfield (154) 747 posts |
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. |
Alan Adams (2486) 1147 posts |
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. |
David J. Ruck (33) 1629 posts |
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. |
Herbert zur Nedden (9470) 39 posts |
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 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). |
Colin Ferris (399) 1809 posts |
Could you have a separate prog that could run through all the files on HDs to point out any possible probs. |
nemo (145) 2529 posts |
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 |
George T. Greenfield (154) 747 posts |
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. |
David J. Ruck (33) 1629 posts |
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. |