LanmanFS trimming files

I’ve noticed saving direct to shares on my nas via lanmanfs is not saving the last chunk of large files. I first noticed saving from StrongEd but found it entirely repeatable with paint. E.g. Create new sprite, same to RAM disc, 8553656 bytes, save again to share, 8488120 bytes… hmm exactly 64k shorter, that’s surly significant.
I’m running a Pi2 and it certainly used to work fine with RO 5.21, though in the summer sometime I started using 5.23 ROMs but it wasn’t until December I realised the common element of some of my file corruption was a lanman issue. I then realised it was repeatable with every large file save (copying via filer seems to work fine though). I tried a few nightly builds in December and the problem persists. I’m quite surprised no one else seems to have reported this yet, so it is entirely possible is a problem specific to lanmanfs and my nas (DLink DNS320L) though I’m not currently able to test to a different device right now. Has anyone else observed or able to recreate this issue?

No problem using LanMan98 version 2.05 (from VRPC). No problem using LanManFS version 2.36 from ARMX6. Sprite 20436536 in length after both saves to RAM and LAN.

Some filing systems do not save the last bit of a file after a ‘1A’ (ctrl-Z) character unless identified as a binary file (0D 0A 1A is end of file for a text file). What file extension did you use and is that in your MimeMap file?

Ok, interesting, I’ve done some messing about and I can’t see anything common in content or size, only that the file must be larger than 64k to have an issue.

I saved straight from paint as ‘SpriteFile’ so no implied / extension. Mimemap has
MIME type: image/x-riscos-sprite, RISC OS file type: &FF9
And indeed if I look on the NAS it has created a file named SpriteFile,ff9 as I’d expected.
So, I found messing about with the type and extension I could not change the behaviour ( I loaded the file to stronged and saved in with different /extensions and types)
I then changed my big white sprite to a jpeg in changFSI and now I could not get it to fail, it was only just over 32k in size. I doubled the data to make a 66534 byte file, saved that to the NAS and ended up with 998 bytes.

So, some sanity checks, using the new sprite I created earlier (1920×1080 16M BGR) I reverted my Pi to RO 5.21 17-feb15, this had LanmanFS 2.47 6 Aug 2014, and it’s all good. Also, exactly the same test with an Iyonix RO 5.22 13-apr 15 LanmanFS 2.48 14 Mar 2015, again all good. Then, updated both Pi and Iyonix to RO 5.23 30 Dec 2016 LanmanFS 2.58 23 Oct 2016, and both now write the file exactly 65536 bytes short.

I’m having issues with ftp right now, so can’t upload my test sprite, but instead, I created a Dump using the ROM LanManFS on the most recent ROM, saved to RAM disk I get 90840 bytes, saved to NAS, I get 25304, 64k short again. Hopefully that’s a repeatable chunk of data to test with. I guess the next step, if no one else is able to repeat this is to get a different network share set up and see if it’s repeatable there. Is there any way I can get versions of LanmanFS between 2.48 and 2.58 to narrow down when the issue may have begun?

Also, exactly the same test with an Iyonix RO 5.22 13-apr 15 LanmanFS 2.48 14 Mar 2015, again all good.

Possibly the change to the buffer use in revision 1.54 (LANManFS 2.50 July 12th 2015) interacting with the buffer information from the server.

Is there any way I can get versions of LanmanFS between 2.48 and 2.58 to narrow down when the issue may have begun?

A collection of LanManFS’s 2.48 to 2.57, less 2.49, taken from !Omni in beta HardDisc4 downloads is here.

I don’t see the issue here using a pen in my Netgear router.

Thanks you, only just had time for a quick test, but yes, the problem exists as early as 2.50, tested on both RO 5.21 & 5.23. I got an abort loading 2.48 on 5.23 so couldn’t test that

I got an abort loading 2.48 on 5.23 so couldn’t test that

So do I!

A full ROM from 17Mar2015 should have LanManFS 2.48 in it, and not abort.

I don’t see the issue here using a pen in my Netgear router.

Thanks you, only just had time for a quick test, but yes, the problem exists as early as 2.50, tested on both RO 5.21 & 5.23.

The at does rather point to either LANManFS misinterpreting the information from the NAS regarding the buffer or the DLink DNS320L sending incorrect info. Perhaps Colin Granville has some test code that can pick up the details and show where the fault lies.

A full ROM from 17Mar2015 should have LanManFS 2.48 in it, and not abort.

Oops, we already have LanManFS 2.48! I do not have anything with LanManFS 2.49 in it, it had a very short life.

Ok, I’ve got to a point where I can build it, so now I know roughly where to start looking I’ll try and have a mess around sometime in the next week or so to see what’s going on. Thanks for the pointers

Sorted…. The short version, I set up another raspberry pi with raspbian to use as a file server to play spot the difference. From the NAS the maxTxBufferSize was set to 131072, samba on rasbian, much smaller, so I configured samba to 131072 and then the issue was perfectly repeatable there too. Anyway, in googling how to set ‘Max Xmit’ on samba, it seemed to indicate it shouldn’t be more than 65536.
It seems reasonable that LanmanFS should keep inside this limit, so I added
hS→hServer→maxTxBufferSize = min(hS→hServer→maxTxBufferSize,65536);
to the end of SMB_Negotiate and voila, a working NAS again.