Dyalog APL Link AutoReload reliability across filesystems

Answer to the question

AutoReload works only when the underlying operating system can deliver a file‑change event to the Dyalog process. In practice the following storage back‑ends are known to suppress or delay these notifications, causing AutoReload to silently miss edits:

• Windows SMB/CIFS shares – the native Windows driver reports changes only when the client is actively polling or when the server sends a lease‑renewal. If the share is mounted with the default Windows options, the ReadDirectoryChangesW API may never fire.
• NFS mounts with noac or async – the NFS client caches file attributes aggressively. On NFSv3 the server may not send change notifications, and the client will only notice a modification when the cache expires.
• FAT32/NTFS on removable media – these file systems do not expose inotify/FSEvents events in the same way as native Linux/Unix file systems, so Dyalog sees no change.
• Loopback or tmpfs mounts inside containers or VMs – the notification semantics differ from a real block device, often resulting in missed events.
• SMB via WSL or Samba on Linux without actimeo or nocto options – the Linux side may coalesce or drop change events, especially under heavy I/O.

Why the silence happens

AutoReload relies on the OS file‑notification API (inotify on Linux, ReadDirectoryChangesW on Windows, FSEvents on macOS). When the file system or network share does not expose these events – either because the protocol lacks them or because the client caches attributes – Dyalog never receives a trigger. The interpreter therefore continues to execute the cached version of the namespace until a manual refresh is requested.

When you should invoke ⎕SE.Link.Refresh manually

There is no hard‑coded threshold in Dyalog, but empirical observation shows:

• More than ~5–10 source files modified in rapid succession on a suspect back‑end usually leads to at least one stale reference.
• Editing a file and reopening it after a minute or more on an NFS/SMB share often yields stale code because the cache has not yet expired.
• Running a long build or script that touches many files can push the inotify watch limit, causing some events to be dropped.

In all of these scenarios, a quick ⎕SE.Link.Refresh guarantees that the interpreter reloads the latest source, restoring a repeatable state.

Practical verification steps

1. Mount a test directory on the suspect backend (e.g., \\server\share on Windows or an NFS mount with noac on Linux).
2. In Dyalog, enable AutoReload for that directory:

   ⎕SE.Link.AutoReload←1
   ⎕SE.Link.Add 'path/to/directory'
   

3. Edit a source file (e.g., change a function’s return value) and immediately execute a command that uses that function. If the new value appears, AutoReload worked.
4. Repeat the edit on the same backend; if the old value still executes, the notification was missed.
5. Run ⎕SE.Link.Refresh and confirm that the updated code now runs.
6. For comparison, repeat the same test on a local ext4 directory – AutoReload should succeed without manual refresh.

Missing diagnostic detail

To refine the recommendation for your environment, could you tell us which OS and mount options you are using for the shared code directory? Knowing that will help identify the exact notification path that may be failing.