SYS GBPB doesn't work in 5.24

Dear all,

Having upgraded to 5.24, the OS_GBPB call no longer seems to work. Perhaps, former versions of the OS have been tolerant regarding my possible misuse of it. Would anyone be so kind to take a look. It’s a routine that reads the contents of a directory, and stores the subsequent entries in  file$().

DEF PROCread_dir
DIM buf% 256
files%=0 : file$()=""
SYS "OS_GBPB",10,"user$dir",buf%,1,files%,255,"*" TO ,,,n%
WHILE n%=1
    files%+=1
    file$(files%) = FNstring(buf%+20)
    SYS "OS_GBPB",10,"user$dir",buf%,1,files%,255,"*" TO ,,,n%
ENDWHILE
ENDPROC

DEF FNstring(p%)
f$=""
WHILE ?p%<>0 f$+=CHR$(?p%) : p%+=1 : ENDWHILE
=f$

I used this routine since years in nearly all of my programs, but since 5.24  n% never gets 0, while the routine keeps reading the first entry only, until it gets out of range. Anyone?

but since 5.24 n% never gets 0

That’s because you’re holding it wrong.

R4 returns -1 when it’s done, and R3 is a count of how many items were read this time which can be zero in the middle of an operation, multiple times, if the FS feels like it.

I’m still running my build of 5.23, but this ought to work…

   10DIM file$(256)
   20files% = 0
   30PROCread_dir
   40
   50FOR l% = 1 TO files%
   60  PRINT STR$(l%)+CHR$(9)+file$(l%)
   70NEXT
   80END
   90
  100:
  110
  120DEF PROCread_dir
  130  DIM buf% 256
  140  files%=0
  150  file$()=""
  160  SYS "OS_GBPB",10,"$",buf%,1,files%,255,"*" TO ,,,n%,r4%
  170  REPEAT
  180    IF (n% <> 0) THEN
  190      files%+=1
  200      file$(files%) = FNstring(buf%+20)
  210      SYS "OS_GBPB",10,"$",buf%,1,files%,255,"*" TO ,,,n%,r4%
  220    ENDIF
  230  UNTIL (r4% = -1)
  240ENDPROC
  250
  260DEF FNstring(p%)
  270  f$=""
  280  WHILE ?p%<>0
  290    f$+=CHR$(?p%)
  300    p%+=1
  310  ENDWHILE
  320=f$

I’m still running my build of 5.23, but this ought to work…

Closer, but still wrong.

  120DEF PROCread_dir
  130  DIM buf% 256
  140  files%=0 : r4%=0
  150  file$()=""
  160  REPEAT
  170    SYS "OS_GBPB",10,"user$dir",buf%,1,r4%,255,"*" TO ,,,n%,r4%
  180    IF (n% <> 0) THEN
  190      files%+=1
  200      file$(files%) = FNstring(buf%+20)
  210    ENDIF
  220  UNTIL (r4% = -1)
  230ENDPROC

The wiki has a pseudocode template which I’m hoping is correct.

https://www.riscosopen.org/wiki/documentation/show/OS_GBPB%2010

Ah, although Rick’s code might work as well, I’ve only tried Jeffrey’s, and that one certainly does the trick. Thank you very much for your quick and supportive answers. What a terrific medium this is!

Now, the only question that remains is: why did my original code work all those years?

It won’t. OS_GBPB won’t be called if n==0

SYS “OS_GBPB”,10,“user$dir”,buf%,1,r4%,255,“*” TO ,,,n%,r4%

Crap! I forgot to check the input parameters, and yes – of course – don’t need to call it twice – that’s DOS not RISC OS. ;-)

Now, the only question that remains is: why did my original code work all those years?

Luck.

Success depended on r4 returning the same value as you set file% to which is not always the case as the r4 value is dependent on a number of factors. The only thing you know for certain is the list starts with r4 = 0 and ends with r4 = -1; the values in between are undefined.

Now, the only question that remains is: why did my original code work all those years?

Similar to the reasons why people using applications that accessed zeropage locations didn’t always see a glitch error or crash when they used them on older versions of the OS, as Colin stated: Luck. You just lucky things worked when really they should have done what they are doing now and failed.

Still, life is a learning experience.

Ah Ha!
This thread has probably saved me a lot of time in bug hunting in my 25+ year old bit of code.
Since upgrading to 5.24 my filename cataloging program has failed to work (the program is to enable a super quick filename search on a external network NAS drive)
Obviously I have assumed it was an OS error thats crept into LanMan/Omniclient and not my code thats been happily running for over a quarter of a century.

Thanks to Jeffrey Lee’s coding insight, I will check my program over the weekend to see if its my use of OS_GBPB,10 is buggy, and not the filesystem.

Funny enough my program will work under 5.24 if I use LanMan98 and not LanMan/Omniclient to access the drive.

Yeah, there have been some significant changes to LanMan over the past few years, so it wouldn’t surprise me if one of those broke software which wasn’t calling OS_GBPB 10 properly.

Maybe Paul’s been using LanMan as well, since I can’t immediately think of any changes to the other filing systems which could have affected this.

Maybe Paul’s been using LanMan as well, since I can’t immediately think of any changes to the other filing systems which could have affected this.

No, I’ve used the routine exclusively for reading local directories. And just as Jeff already mentioned, this routine dates from the dawn of RISC OS.
Strangely, the very same GBPB call that reads the very same directory on 5.24 sucks, while it has run happily on all former incarnations. Well, it’s strange to me, at least.

I had a bit of time this afternoon to find out why my file search program was failing under 5.24
I was amazed to find out that my quarter of a century old program was not abusing OS_GBPB 10, and my program is 1000% bug free :-)

After a bit of detective work I found out the reason for it not working is a LanMan/OmniClient problem.

If under LanMan you try to access a file which is stored in a folder, and the folder has a forward slash and a space (or hard space) anywhere in its name (these 2 characters have not got to be together) you will get a ‘file not found’ error.

I’m not sure if it’s a new or a longstanding LanMan bug is I usually use lanman98, but as I just updated to 5.24 I thought I give LanMan a try out. I think this bug may be eventually fatal, as while trying out different combinations of folder names I’ve managed to crash my raspberry pi.

Probably this should be started as a new thread under bugs, but yes, I can confirm I too can see issues with space and / in a folder name via Lanman.
(Currently on pi Rom 5.25 29apr)

Creating a folder on a network share with a space is fine, or a / is fine, but using a combo results in a seemingly random(1) folder name. E.g. Space/ results in _IDZPL~F
Seems something is lost in translation.

(1) The same input always results in the same output.

Yes Will I should of put this under bugs, but were here now :-)
It seems that in your 5.25 rom that your bug is slightly different from mine. My problem is trying to access files that are stored in a folder with a ‘/’ and space (or hard space) in its name, the folder name is displayed correctly.

But if your saying that in 5.25 your folder name changes, under 5.24 or less it doesn’t, then I agree with your idea that its a filename translation problem, and in the new 5.25 rom its displaying what the translated filename is, but in earlier versions it doesn’t, and thats why I can’t access any files stored in the dodgy named folder (because LanMan changed the folder name without telling the filing system, so the files stored in that folder can’t be accessed because the pathway names won’t match up…. if you see what I mean).

A quick test shows, if I create a folder on my nas first, say “a b.c” it displays as I’d expect, “a b/c” in the filer, but is inaccessible to write to, as you’ve observed. I’ll have a closer look at the name translation code when I’m able.

People are talking about shares with spaces in the name and seem surprised that the sharing doesn’t work reliably or at all.

I’m curious why anyone expects something that doesn’t work reliably between two Windows devices to work with any other device after all “spaces are delimiters” is the mantra my Unix colleague at work trots out.

The CIFS standard documents actually state that

Dialects prior to LAN Manager 2.0 required that file and directory names adhere to the 8.3 name format. Names of this format consist of two parts: a basename of no more than eight characters, and an extension of no more than three characters. The basename and extension are separated by a “.” (period). All characters are legal in the basename and extension except:

The space character (0×20)

"\/[]:+|<>=;?,*.

The LAN Manager 2.0 dialect introduced the SMB_FLAGS2_KNOWS_LONG_NAMES flag. If a client or server sets this flag in its messages, this indicates that they are not bound by the 8.3 name convention and support long file and directory names. Long names have MUST a total length of less than 255 characters. The following characters are illegal in a long name:

"\/[]:+|<>=;?,*

A “.” (period) is treated as a delimiter of file name components. The 8.3 name format uses the period to separate the filename from the file extension.

You will note that the Microsoft botch that makes spaces in file and directory names common within Windows actually breaks the CIFS sharing but elsewhere they insert another botch which allows for spaces in the share if the whole name or entity is enclosed in quotes.
That specific case has produced so many access issues at work that the MS server guys simply don’t build shares that way.

Short answer; Don’t use spaces in file or directory names where you intend to share in this fashion and avoid the other illegal characters too.

that doesn’t work reliably between two Windows devices to work

Should I be American and raise my arms and shout hallelujah?

In my experience, sharing between two Windows machines either works brilliantly or not at all, with no clear reason why. I’ve found using SMB between non-Windows devices to be more reliable, but even then it’s hit and miss.

Example? A few weeks (months?) ago I posted that I fired up a simple web server on my PC because SMB to the Pi was coming in at a rate of bytes per second. Two days ago? Worked fine. Same setup. Hmm…?

Luckily for me Windows & Acorns have lived happily with each other as long as the shared files are on a separate NAS drive (nightmare otherwise).
As for spaces in filenames (or folder names)…. yeah, good knows how many times I’ve told the staff here not use them, only use letters, numbers, and use a minus sign for a space but….

I have been thinking about writing a little program to hunt out badly named files/folders and rename them, but as long as the acorns are using lanman98 life is ok, and I can worry about other problems …. the joys of running a small engineering company!

As for spaces in filenames (or folder names)…. yeah, good knows how many times I’ve told the staff here not use them, only use letters, numbers, and use a minus sign for a space but….

My vote for the most moronic feature of MS Office is the default name feature: Create a file and put in a title of “My-latest-thoughts” and make a save – the application drops in a suggested filename of “My” (break the name at the first non-alphabetic character) but do the same sequence with a title of “My latest thoughts” and it offers a suggested filename of “My latest thoughts”
Yup, it actively encourages people to produce filenames that are likely to cause problems.

I have been thinking about writing a little program to hunt out badly named files/folders and rename them,

Our Unix bod was running a scheduled script on one box that renamed all badly named files each night, just before the backup routine. That box has gone but I’ll try and remember to ask if he still has the script.

Thanks for script offer Steve, but i’ve only got to do some small changes to my nightly file cataloguing program (for a super fast search on the acorn machines) and so far…. touch wood… it’s only been an issue while experimenting in using LanMan instead of LanMan98

Cross client and server compatibility is a nightmare with SMB concerning allowed characters. Samba and its strange configuration options wrt encoding handling play a role here – reports that LanManFS (or LanMan98 or Windows or Linux) work fine with one NAS but not with another are common when it comes e.g. to storing filenames with non-ASCII characters like German Umlaute. It gets even more interesting if you start to use Sunfish in parallel on the same NAS. By choosing specific characters for files in Sunfish, you can “hide” them from LanManFS.

Sometimes I think we should all fall back to ISO9660 Level 1: 8+3, upper case only, only letters and digits and the underscore.

Sometimes I think we should all fall back to ISO9660 Level 1

Or hire API designers/programmers who can think past the “what I expect them to do” trap.

Or hire API designers/programmers who can think past the “what I expect them to do” trap.

Ah, but it is all open source, so we are supposed to fix it ourselves :-)

To be fair to both Sun (NFS) and Microsoft (SMB/CIFS), I think the API and the specs are not the problem. It is the very varied quality of the implementations. If you are using their latest incarnations at least, where the encoding stuff is well-defined instead of more-or-less-random.