LanManFS and special filename characters

When trying to copy or backup files to an NAS using LanManFS, it always chokes when it reaches a directory such as \svn.

LanMan98 has a sysvar <LanMan98$ShowHidden> which if set allows it to cope with e.g. \svn, and file copies/backups occur without interruption. Is there any way to get LanManFS to deal with such files?

I had a similar problem with directories (or maybe files?) and there is some code in LanManFS which does all sorts of funky filename translation. I started sifting through it, but Colin arrived with the answer in a patch!

So first thing… Are you on a recent LanManFS?

Are you on a recent LanManFS?

Well, I guess so. It is v. 2.66 (31 Aug 2020) in ROM, on both the Titanium and ARMX6.

Just to add – there was a typo in my original post. The problem directories or files are of the form /svn, i.e. a forward slash.

While the PRM (pages 2-10 to 2-12) deprecates the use of a backslash (\) in a filename or directory name it does permit a forward slash (/) so LanManFS should be able to handle it. Perhaps it could substitute one of the deprecated characters that have a special meaning in RISC OS but not in Unix – such as & @ or % which it knows cannot exist in a RISC OS filename. Top bit set characters are allowed in RISC OS filenames but ‘should be avoided’, not sure whether Unix allows them. LanManFS is also, presumably, agnostic to the case of a letter.

While the PRM (pages 2-10 to 2-12) deprecates the use of a backslash (\)

It does? It says that it has “special significance”, and so may not be used in filenames. There’s no suggestion that it’s ever been allowed.

While the PRM (pages 2-10 to 2-12) deprecates the use of a backslash (\)

It does? It says that it has “special significance”, and so may not be used in filenames. There’s no suggestion that it’s ever been allowed.

Wrong place. Since files normally get created, named and transferred by Users I’d say that unless the admonishment/prohibition is in the User Guide you have an uphill battle.¹
30+ years of IT support and PC/Windows users demonstrate that no matter how stupid an idea putting spaces in filenames might be they will do it.² Years of education fail, because no one wrote it in big letters.³

In short, it should exist as a prohibition in the User Guide, it should exist as a conversion in the OS

Perhaps it could substitute one of the deprecated characters that have a special meaning in RISC OS but not in Unix – such as & @ or % which it knows cannot exist in a RISC OS filename.

Never, ever suggest that a programme or the OS should substitute with any character that is not platform agnostic

¹ Pithier phrases came to mind, anyway, unless a cattle prod is involved users will still do the wrong thing if it’s possible.

I’d say that unless the admonishment/prohibition is in the User Guide you have an uphill battle.

It’s there. Page 17 of the A3000 User Guide, page 18 of the RISC OS 3 User Guide, page 11 of the RISC OS 3.6 User Guide and page 36 of the RISC OS 5.24 User Guide.

Interestingly, the original Archimedes User Guide doesn’t list it as prohibited, although it does state it has a special meaning (“previous directory”) on page 95.

It’s there. Page 17 of the A3000 User Guide, page 18 of the RISC OS 3 User Guide, page 11 of the RISC OS 3.6 User Guide and page 36 of the RISC OS 5.24 User Guide.

Ah, but I did say:

unless a cattle prod is involved users will still do the wrong thing if it’s possible.

So, after all the years since RO3 the problem still occurs. Clearly Acorn missed the point that users will <insert as appropriate> unless you prevent it.
Does anyone know where to look to make such things impossible and know how to amend that bit?

In the share on Unix box I mentioned the sysadmin simply scheduled the rename process to run every night, just before the backup so it didn’t matter how often the users did it, the spaces disappeared overnight.

Are you seeing the /svn folder in LanMan98? If so the ‘/’ is translated from a ‘.’ which makes the folder hidden and LanManFS doesn’t see hidden files/dirs. There is a flag to make hidden files visible in the code but no way to set it. It is explicitly excluded from *Lanman:LMNamemode.

I find it useful not to see hidden objects when copying the code from a git repository I’ve cloned on linux as it avoids copying the .git directory but the downside is you can’t delete a folder containing a hidden file.

It’s easy enough to change if rool decided they wanted to change it.

Does anyone know where to look to make such things impossible and know how to amend that bit?

In the specific case of \ it’s already been done. Trying to save a file called “TextFile\2” gives the error “Name not recognised”.

BTW, saving the file as “\.TextFile” does save it to the PSD, but the filename in the document window appears as “\.TextFile” (instead of SCSI::HardDisc4.$.TextFile) and a subsequent save won’t necessarily overwrite the file just saved: the file gets saved to whatever PSD happens to be at the time of the save. A similar thing happens if you use a filename of “%.TextFile” (which uses CSD). Ah, the mysteries of RISC OS…

Then some brain-dead programmer produces a version of Word that automatically generates the filename default from the title

in fact it created the document name from the first paragraph, which for sensible documents was usually the title. I’ve seen, in a school setting, document names of around 250 characters. I’m not sure whether word imposed a limit on the length of names or not.

Dragging those to RISC OS could get interesting.

Maybe I should put this in to context a bit. It is not me inventing the directory name /svn, or some of the filenames in such directories. I use !SVN to keep a track of all the changes to my various software projects. It is the port of SVN that uses these unixy path names – I have no control over it. However, it does create problems when copying to or backing up to e.g. an NAS, which has a unix derived operating system. LanMan98 can be set to cope, but I have been trying to convert more to using LanManFS, since it is part of RISC OS and is being developed.

It’s easy enough to change if rool decided they wanted to change it.

Maybe a user setting as in LanMan98?

in fact it created the document name from the first paragraph, which for sensible documents was usually the title.

Yeah, I know. I just couldn’t be bothered typing out something of that length

LanMan98 can be set to cope, but I have been trying to convert more to using LanManFS, since it is part of RISC OS and is being developed.

Wasn’t there something from Andrew regarding having obtained the source for LANMan98 and that he was supposed to be getting it added to the ROOL source?
(From the Virtual show presentation I think)

Would you like to try lanman_hidden to see if it works as you expect?

It adds:

show hiddenfiles:

*lanman:lmnamemode 3


hide hidden files:

*lanman:lmnamemode 4

Wasn’t there something from Andrew regarding having obtained the source for LANMan98 and that he was supposed to be getting it added to the ROOL source?

Well it’s been added to PlingStore as a free download with source code…

Would you like to try lanman_hidden to see if it works as you expect?

Thanks Colin – I will give it a whirl later today.

back to the drawing board – delete hidden file doesn’t work

Colin – that version seems to do the necessary. I transferred to the NAS snapshots of the DPlngScan and SyncDiscs projects taken back in February. Both could be synced with the current state of the projects without any glitch, and the log files showed all the svn stuff (in /svn folders) had been updated correctly. Many thanks. That seems to be me sorted anyway!

delete hidden file doesn’t work

Ahhh – that wouldn’t have shown up. I did not have a scrap directory configured, so the files in question were not being deleted, only updated.

lanman_hidden should work now. The help lanmanfs shows version a2