LanManFS losing directory contents after a while

This is a long running problem, but having banged my head against it all afternoon, I thought it was worth raising again as it would be nice to see it solved.

If you connect to a shared drive (eg. NAS – I’ve seen this on several QNAP and Synology NAS devices) for the first time in a session, all will be well. If you leave it connected but unused (say for 30mins), and then open a new folder (or an existing one), many of the items will be missing. Typically, if a folder contains 50 items, maybe 10-20 will appear.

What is disconcerting is that there’s no way to know if what you’re seeing is “real” or just LanManFS going wrong.

Dismounting and re-connecting is not enough to resolve the issue – LanManFS has to be rmreinit-ed and then the drive re-mounted.

I assume it is something to do with idle timeouts/disconnects, but the way in which it seemingly “caches” the bad data makes it a particular hassle.

I’ve seen this on both ARMX6 and Titanium, so I don’t believe it to be a network interface/driver issue. Also, LM98 seems unaffected reinforcing that the fault would appear to lie in LanManFS.

If others can reproduce or have encountered this, that’d be helpful info too.

Yes I’ve seen this/similar problem on my Pi’s(?) linked to my NAS (Netgear).

I found that dodgy characters in the file/folder name causes LanManFS problems (files not shown etc).

But also when I was playing around with LanManFS (when I upgraded to os 5.24) I have seen files not being shown (which are there) in the filer window, which it showed correctly a few hours/days ago. I assumed it was caused by LanManFS slowly crashing (caused by the dodgy file name it had seen at some point?), so I abandoned my LanMan testing and went back to using LM98.

I think the problem has been recently recognised and corrected in LanManFS.

Chris, do you happen to know how “recent”? I don’t recall any relevant CVS logs, and I’m testing with fairly up-to-date ROMs (min 5.24). It’d be a big help if this has been fixed though!

April 16th 2016

Not a fix but a possible work around. I don’t use LanManFS. IIRC under certain circumstances LanMan98 doesn’t show updates to a directory (e.g. a file being saved locally). Saving a dummy file into the directory causes its windows to be updated with all files shown.

To add, I’ve certainly seen the problem, with files I know are there and just not showing, and I would have said more recent than 2016 (I could be wrong though), although it is so infrequent that after the first time I saw it, and failed to find any way to recreate it, I hadn’t given it much thought. I use my nas as my main file storage from my pi, and often go weeks between reboots with it mounted. I’ll add to this if I do witness it again.

This is definitely different to the 2016 fixes, I’m afraid. The simple way to reproduce it is to leave LanManFS idle for approx 30 mins or so (go have dinner whilst still connected) then try opening some folders. You’ll almost certainly find that some files are missing. Whether this is specific to some NAS Samba implementations, I don’t know (as I say, I’ve had it reported on QNAP and Synology NAS devices with a variety of firmwares, but those tend to be the only LanMan servers we connect to).

If reproducing is a problem, I’ll check with Richard and John – between us we should have a loner NAS that we can provide, if there’s dev time available.

Are the same files going missing or does it look like the missing files are just random? Does counting a folder count the correct number?

Yesterday (saturday, midday ish) I downloaded os 5.25 (july 20) to see if there had been any changes to this problem.
All I done was to examine folders stored on my Nas and open up a few pipedream files and text files.
Every thing seemed ok until about an hour ago when a lot of files are not shown, and the system was idle between it being ok at 9am this morning to 11am(ish) when it was not ok, which seems to indicate some sort of time related problem (as it seemed to me when I tried it on os 5.24 a few months ago)

If I look in directories that are shown, some of the files and folders in there are missing (but not always!). But it is consistent ie its the same files/folders are always shown as missing if you open/close/open folders. With the missing files/folders I can’t see pattern (file name wise), and as suggested by Colin when I do a file count, it is incorrect in the folders that when opened don’t show all the files/folders.

Has anyone reproduced this when connected to a windows machine?

My first attempt to reproduce the problem by connecting to a windows laptop and leaving it for an hour didn’t reproduce any problems.

Does selecting refresh for the folder do anything?

Are the missing files immediately after folders?

Does how the display is sorted or whether you are using large icons, detail etc. make any difference?

Refresh does not change anything or does how the display is sorted and the missing files don’t seem to be after folders.

I wonder if simpler displays using commands like *Cat and *Ex also show the same problem as the Filer?

And at an even lower level, what about SYS OS_GBPB 9-12 ?

It might be worth performing a *Cat command on the corresponding folders and compare the results of the same command when the problem is not present. It may be that the list provided is just truncated (or skipping the first entries due to an index initialisation issue) but *Cat provides an unsorted view of the folder’s content while the Filer sort’s the folder’s content and may hide the issue.

I’ll go do a star-cat, but in the meantime, I’ll re-iterate that the only fix we’ve seen is *rmreinit lanmanfs Dismounting/re-mounting is not enough, the problem persists until LanManFS is reinitialised.

If anyone is interested, I now have a very crude simple program which will list the contents (using OS_GBPB) of a given directory (and the contents of any subdirectories) at defined intervals (eg 60 minutes) and raise an error if the file & directory counts are different to the previous ones. It works to my Synology NAS using LanMan v2.61, but I have not seen any discrepancies (yet!).

This might help to discover if OS_GBPB is also affected, and if so to narrow down when it happens.

pm me to riscos at avisoft dot co dot uk if you would like a copy.

cat displays the wrong contents as well, and also in some folders I looked into it (cat) list is not always the same info as in the filer window.

If I remember correctly in my testing I done a few months ago OS_GBPB is affected.

I’ve now reset the Pi and I will leave it idle just to see if it goes wrong in roughly the same amount of time (around 11 hours last time).

I have had my program running hourly checks for the last 6 hours, and each check has found 469 directories and 32,364 files. The machine and LanMan were otherwise largely idle during this time.

Yes, for some reason I couldn’t get it to happen whilst testing the “release ROM” for the Mini.m yesterday. Most frustrating, as it caused me no end of hassle on Friday on my Ti, and Richard frequently comments about it on his ARMX6.

Martin – could you email me the program and I’ll ask Richard to try it – he sees it frequently as he has multiple NAS units up 24/7.

Andrew: program emailed to rcomp@ . Oops no – failed 550-Relay Denied! Temporarily blocked due to suspicious ??

Failed again, so sent direct to Richard.

What is the mechanism by which SMB notifies the clients of changes to the directory structure(s)? I can’t imagine it is efficient for the client to keep requesting the directory contents over and over and over…

Maybe this is getting out of sync?

But I thought the remote filesystem was unused & unchanged but things vanished? No sync should have been required.

The messages say about leaving LanMan idle, but don’t specify if any filesystem activity is happening on the NAS from elsewhere.

Hmmm. Indeed true Rick. That needs to be clarified.

Shouldn’t make any difference.

When opening a directory or typing *cat the full directory is enumerated. You can see what happens in wireshark. The file names are fetched a few at a time. So if you open a directory and filenames are missing that implies the directory enumeration has failed. The fact that the missing filenames are not at the end of the directory list suggests that the missing filenames have been received because the last filename fetched is used to fetch the next batch.

It is odd that time is a factor as I don’t see why it would be.

I can’t reproduce the problem on windows – which is a shame as wireshark would show what is happening. The only thing I can think of different on a NAS to windows is that NAS software tends to negotiate a larger buffer size so would transfer more filenames in one chunk.