LanManFS (Omni) and slashes in filenames

Hi all,

I’ve got a small Linux box which shares a vFAT USB stick with Samba. LanManFS connects to this nicely from my Pi.

My RISC OS ROM is from 11th May. LanManFS is 2.61 (3rd Jan).

If I create directory called ‘q/+’ (yes, queue-slash-plus!) then I cannot copy anything into it – I get a ‘directory not found’ error.

Connecting to the Linux box reveals that it has really created a directory called ‘q.+’, presumably because a slash cannot be used in filenames in Linux.

I’m not sure where the responsibility lies for this one. Is it LanManFS, which should perhaps do some translation? Or is is more likely to be Samba, or the Linux vFAT filesystem support?

Has anyone seen similar issues on other systems, e.g. filenames with backslashes on Windows systems?

Cheers,
Richard.

It’s pretty much been the case since RISC OS 3 that file extension separators in FAT are replaced by slashes because a period is a directory separator:
$.MyDir.MYFILE/DOC
would be copied to a FAT media device as:
MYFILE.DOC

That’s probably what is happening here. It’s just convention that ‘.’ (other OS) is ‘/’ (RISC OS).

Yup see the same on LanManFS 2.58 and RISC OS 5.23.

Why do you need such an odd filename?

Rick,

I agree that on FAT media, the magic of DOSFS, will do as you say. Not sure what it would do with ‘X/Y/DOC’ as a filename, though! But in this case, RISC OS and LanManFS have no idea that the target filesystem is FAT. In fact, Samba on the Linux box doesn’t even know that it’s FAT – after all, it’s just exporting a directory.

Glen,

I was commiting the crime of backing up the contents of my Pi SD card (the whole shebang, rather than the bits I cannot find elsewhere). I have a directory called ‘AcornC/C++’ and whenever the copy process got to that directory, it stopped with ‘directory not found’. I was mucking around last night trying to see what the simplest directory name was that caused the problem!

I appreciate that it’s a bit of a strange one, but I wondered if somewhere in the chain, some substitution might be missing. But I’m not even sure if its LanManFS to blame (I did have a brief browse of the LanManFS source!). I’m, starting to suspect that I need some hackery with my Samba config to make it FAT-aware.

Ah that makes sense!

You could try zipping it all up before the backup?

Or if you have a way of plugging it into the Linux server you could back it up to an image using the dd command (possibly by connecting to it using NettleSSH?)

https://raspberrypi.stackexchange.com/questions/311/how-do-i-backup-my-raspberry-pi

Finally you could try exporting an NFS share and using SunFish (although I can’t say for sure if the behaviour would be any different!)

http://www.cp15.org/internet/

There are a lot of rules for a lot of filing systems, along with a lot of configuration options on the Samba side. I had a lot of fun trying to sensibly handling encoding stuff like ISO8859-1 umlauts.

LanManFS has the translation “/” to “.” and back hard-coded. There is no way around. And it is not a problem, since every LanManFS target system allows “.” as a character and actually disallows “/” as a character. So this is entirely sensible.

There are of course any number of quirks you might encounter. Like e.g. FAT not allowing a directory to end with a “.” character or a space. Maybe the “+” is the problem and not the “.”? Try it and see.

If you want to reach the next level, try to configure your system so that SMB clients and NFS clients and FTP clients on all operating systems can interchangeably and correctly load and save files with names consisting of all characters that are allowed on the client FS. See you in a few years :-)

I began looking at this a while back, although I’ve not had time to get far. Doing the same, backup to a nas, I found in !zapuser, I think, with -> in the filename also caused diretory not found. Not near my pi at the moment but from what I remember; lanmanfs was able to create the directories with special chars and display them but not manage to hunt down what they were called at the far end when writing files to them. As found in another thread here, it’s more an issue having more than one special char in a name. Also, lanmanfs seems to use quite a different mapping of special chars than lanman98, which actually seems to manage much better.

Yes, that is the odd thing. LanManFS is fine making and displaying the directory, so the conversion between . and / seems OK in principle. But when you try to write a file inside the directory, it barfs.

I have pondered various workarounds, but I am convinced that there is a bug lurking here somewhere. I shall try to find some time to read over the sources (I should also release another version of USBJoystick…).

Thanks for the comments everyone.