Issue with LXA no-type files with failing to copy/write to NAS

I suspect this relates to the changes here https://gitlab.riscosopen.org/RiscOS/Sources/Networking/Omni/Protocols/OmniLanManFS/commit/ddfde4f45ba0de074bace12664dcaa457799ebc2

I’m using the 28th August LanManFS

When backing up folders of files to a Qnap NAS, this now causes many problems. It would appear that some part of the system is trying to write file,lxa as before, but this fails (on a 2MB file, but also on others) giving Access Denied or other permission-type problems. Attempting to delete such a file (to replace it with a different filetype) resulted in a “Pointer dereference” error message.

This is a problem because many old games and the like use files without filetypes, and these now generate errors whenever I attempt to transfer them to the NAS.

I’d be happy to work with / assist in testing any possible fix. If anyone needs more info drop me an email.

Followup – this looks like my mistake – the content I was backing up appeared to have files called file,lxa in it, which then failed to copy correctly. Not entirely surprising as they shouldn’t have been there. I think there may still be an issue (since the file copy failed and crashed the filer/wimp), but it isn’t the one I thought it was and described above.

Essentially someone has provided me with some files with ,lxa appended to the (RISC OS) names, which shouldn’t have been there in the first place. On the other hand, things shouldn’t blow up when those are copied to the NAS.

How deep is the path? A load/exec suffix may take seventeen bytes beyond the comma as opposed to the old ‘lxa’ three. There’s a 512 byte sized buffer that the name, with new suffix, is copied via.