Workaround implemented for file timestamp issue

A few months ago, I wrote a blog post about a problem related to the date modified timestamp on a database file not updating immediately after the file was modified. This was causing a problem with an application I wrote that relied on this timestamp to update the data it displayed on the screen to the end user. It would take around ten seconds for the timestamp to update, which meant that the user had to wait that amount of time before the most recent information was displayed to them.

While I did discover a clue as to why this was happening to some files and not others, I wasn't able to fix the core issue itself--the delayed updating of the date modified timestamp. However, I implemented a workaround that not only solved the problem of the end user getting delayed updates, but also improved the integrity of the file (an Access database file).

The workaround involved creating a lock file whenever a user writes to the database. When the user is done writing to the database, the application deletes the lock file. The application monitors for this file deletion event and refreshes itself whenever a deletion is detected. There are no delays in the file system reporting when a file is deleted, which means the user's screen updates instantaneously whenever the database is updated.

I also use the lock file to improve the integrity of the database file. If the user tries to write to the database, but the application detects the presence of the lock file, it means another user is currently writing to the database. If this happens, the application waits until the lock file is deleted before creating its own lock file and executing its own writes. This prevents multiple users from writing to the database simultaneously and potentially corrupting the database.

There is a second kind of lock file which the application also makes use of. If the file is opened in Microsoft Access, Access creates its own lock file. My application monitors for the presence of this lock file. If the user tries to write to the database while the Access lock file exists, the application cancels the write operation and displays an error message. The error message informs the user that the database is open in Access and that it cannot write to the database while Access is open. This also helps to prevent file corruption.

Similarly to the lock file that the application creates when the user writes to the database, the application uses the Access lock file to detect changes to the database. When the Access lock file is deleted, it not only means that Access has been closed, but that changes could have been made to the database while it was open. So, when this lock file is deleted, the application refreshes itself and updates the on-screen information for the end user.

This workaround has been in production for 1-2 months and has been working quite well.