3.4-rc1: different behaviour for absolute paths in M98

[resam]

Small call out because I couldn't find anything about it in the changelogs:

I'm now running Duet 2 with SBC and 3.4-rc1 firmware, DSF, DWC, etc.

I previously used to call macros and other sys gcode files with M98 P"0:sys/partial-homez.g".

With 3.4-rc1 this is no longer valid, because apparently the path was not absolute.
The now valid way of specifying the path is: M98 P"0:/sys/partial-homez.g".

Not sure if my code just worked by accident in previous versions, or if this is a new change that is not documented yet?

[Stephen6309]

@resam I've always had to use a full path, "/macros/PLAOffset", it couldn't find it without the "/macros/" or "/sys/". The 0: hasn't been needed.

[Phaedrux]

@resam said in 3.4-rc1: different behaviour for absolute paths in M98:

my code just worked by accident in previous versions

I think so. P"0:sys/ sticks out to me like a sore thumb. There's a drive call without a slash.

[resam]

@phaedrux I never thought about it... in my mind the 0: served the same as / to anchor a path to the "root".
Apparently I just got lucky for the last years. I'm using this on multiple places since at least 2019!

[chrishamm]

@resam You are right, it should work in SBC mode as well since FatFs supports paths like 0:sys/foobar. I'll fix it in v3.4-rc2.

[resam]

@chrishamm thanks!

just a small nitpick: this commit looks like that now the following paths are valid, is this intended, or were you looking for the ? regex operator?

0:asdf/foobar.bin
0:/asdf/foobar.bin
0:///////way/too/many/leading/slashes/foobar.bin

On second thought, the regex probably doesn't need the /* at all, it's already covered by the second group with .*

[chrishamm]

@resam It was a shorthand version to ignore double (or even triple) slashes which are also permitted by FatFs, see http://elm-chan.org/fsw/ff/doc/filename.html But I suppose having /?/? instead of /* would also work.