ShareFS inconsistencies

I have noticed a problem with ShareFS filer displays not updating when files are updated on the remote Share. For example, I have made some changes to some source files on the PandaRO and the filer display on that definitely shows the date stamps as being this morning. However, the same directory of files, when viewed via ShareFS on the Iyonix, show date stamps for yesterday or two days ago. Refresh in the filer menu does not update the display.

I have began to realise this phenomenon has been happening because I regularly resync the backup on the Iyonix with the PandaRO, and SyncDiscs reports the directories are the same when in fact they are not. I only realised this by checking the log files of SyncDiscs actions for the backups which run automatically (unfortunately logs of only the last few jobs are kept). I initially suspected a problem with SyncDiscs (suspect your own software first), but I am pretty sure it is the filer not updating the file info for the remote shared drive.

Once I have noticed the filer displays are out of sync, the only way I can get the filer display to reflect the changes is to dismount the share and then remount it. I normally run my machines 24/7 and leave shares mounted all the time. I have no idea at the moment whether this is something happening all the time, or whether it is related to the time elapsed since the share was initially mounted.

RISC OS versions are 28-Nov-2014 on the Iyonix and 16-Nov-2014 on the PandaRO. Has anyone else ever noticed anything like this?

I noticed this some time ago and my solution was to rename the parent directory (on the computer viewing the remote machine) to itself and reopen it. This updates the newly added files and date stamps of altered files. There is no ‘Refresh’ option on the filer menu on my Iyonix as there is on VRPC which has the same fffect of forcing an update. You need to do the ‘refresh’ on the machine with the filer window open, not on the remote machine.

You need to do the ‘refresh’ on the machine with the filer window open, not on the remote machine.

Yes, of course, that is what I am doing. My Iyonix is running recent 5.21, and there is certainly a refresh option in its filer windows. Unfortunately, it doesn’t seem to actually do a refresh.

Anyway – at least it is not just me! I guess the easiest work around is to get in the habit of dismounting the shares when they are not actually being used.

If you are running QuickFiler, F11 should do a refresh.
I cannot remember how I got the program to do it!

Does writing a new file or deleting one force a refresh?
That causes a refresh for LanMan98. But yes it should be necessary.
I can’t recall seeing the problem here.

I think the problem comes when the remote computer alters the file. There is no prompt on the viewing computer to update the filer display.

I think the problem comes when the remote computer alters the file.

Well, yes – that is the point. I cannot say that I have thought about this before, but surely the whole thing loses its point if changes to files are not reflected in the remote viewer. One assumes the ‘Refresh’ option in the filer view is meant to deal with this situation, but it doesn’t seem to.

Refresh works for me on VRPC.

It is not only the filer display. SyncDiscs gets lost as well. I have just been checking the source. It uses OS_GBPB 10 to read the entries and file information from each directory. If it is sometimes reading outdated information, this presumably means that the filer on the machine that has the share mounted (and on which SyncDiscs is running – pulling files preferred over ShareFS) is caching the information. Am I correct in assuming that the caching will only occur when the directory is viewed? This would then make the behaviour intermittent, depending on whether the directory in question had actually been viewed at some time before SyncDiscs starts doing its stuff.

Looks like I need to try a more in depth look at this when I have the time.

Refresh works for me on VRPC.

I am using native hardware with 5.21 OS.