Hi Mikael,

* We already use ReadDirectoryChanges on Windows to find changes fast. It has been out for years already.
* We have something similar on Linux too, using inotify... but since it is quite broken (you need to increase the number of max open files by hand on your system) it is not something we love. We released FTS support to find changes fast a few months ago (same directory walk API that the find command uses).
* We tried to use FSEvents but the tracking of moved files is ... totally broken. No way to do it correctly, so we are not using it at this point.

On Windows, we also released USN Journal support back on May: https://www.plasticscm.com/download/releasenotes/6.0.16.1151. Still sort of experimental, but totally usable.

Could you *please* implement at least the "*very* least" suggestion from the original post - an option to warn at Checkin if a Refresh would bring in additional changes?

We too have fallen many many times into the trap of performing a Checkin, then discovering that a few changed items were not included.

There are OS-specific APIs which allow you to receive OS notifications when activity happens in folders. If you were to use these APIs, you would be able to get an exact list of which files have been touched, and you would only need to check the content of files that have been affected. You would not have to rely on file time stamps any more.

I have seen this used well for an incremental build system that was part of a Windows-only application. It can be done for Win+Mac+Linux but it is a lot more work, and the improved solution will not work for 100% of users (because of how they have chosen to configure their machines).

Windows APIs: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx
ReadDirectoryChanges is a simple API for watching for changes while your application is running. It should work well for local NTFS drives, I don't know how it behaves against network drives.
The Change Journal (aka USN Journal)) allows you to monitor changes even when your application is not running. It only works when you are connecting directly to NTFS volumes. It is probably not supported when you talk to any network drives using Samba or similar protocols.

MacOSX API: https://developer.apple.com/library/content/documentation/Darwin/Conceptual/FSEvents_ProgGuide/UsingtheFSEventsFramework/UsingtheFSEventsFramework.html
Regular events for when the Plastic client is running; persistent events for watching for changes even when the Plastic client is not running

Linux API: https://en.wikipedia.org/wiki/Inotify
The Linux API is not as suitable for Plastic's use case. Inotify will notify you about changes while your application is running. Inotify will require you to traverse the entire folder hierarchy and register for notifications on each individual folder. I am unsure whether the notifications will arrive for NFS mounted drives. I have not been able to find any Linux API that gives you change information when your application is not running.

All in all, it looks like there is good, but not bullet proof, support for Win + MacOSX and spotty support for Linux. All three platforms still need the old timestamps/content logic in cases where users have placed their workspaces on networked drives. In addition, when the Plastic client starts up on a Linux machine, there is no quick way for it to find out what the current state is, so the Plastic client would need to either scan the contents of all files or do a scan using on the old timestamp/contents logic there.

Definitely not the first time we get such request.

Problem is, as you point, potential refresh speed, but it can be an option. Uhm... a good one to check. We'll try. I won't be hard.