Our method for testing whether a file is still in use is a two-part process. I'll summarize how I would apply the process to what you described.
First, we get someone in authority to send out a fairly wide-ranging message saying you will be looking to remove obsolete databases that are unused in the last x months. Warn that if no one claims the database after you mark it, the next monthly cycle of marking old databases will remove all marked files.
Then, we would look for the date of last modification. You can do this from within Access using the File System Object (q.v. in Access Help; a.k.a. FSO) and find all files for which the DateDiff between NOW() and the last modification date is > 3 months or 6 months or pick your favorite time limit. Whatever you use for X, state that time interval.
Mechanically, if you haven't used it, FSO allows you to search files by name and generate a collection. You can then do a "For Each" loop in VBA to process the files found by the FSO search. Each file's attributes are available to you when you select the file out of the FSO collection, so date of last modification should be there.
Next we change the permissions on all files not modified more recently than our cutoff date. (Not sure whether you can do that so easily from Access via FSO, but you can at least build a list of all files showing fully qualified path - 'cause FSO gives you that.)
Then we do this again next month, creating a sliding window of files that weren't selected before, but ARE selected now. This leads to two lists eventually. One list is the files that are x+1 months old and ripe for backup and deletion. The other is the list of files that are ready to be write-locked. Or, in fact, READ locked. You can mark the file to be READ/WRITE locked and still have it visible, because the ability to see the file in a directory listing is a function of the permission on the directory, not on the file itself.
OK, so in the case where the database is legit and still should be active, the user tries to access the DB and can't get there from here - 'cause it is locked by permissions. So the user has to call your department and whimper constructively about why this file should still be available. At this point you get to be the user's friend by unblocking the file.
Once this behavior has been published for a while and things start falling off your server due to age, the message will get around. And if it doesn't, ... hey, you gave them a warning. You can't help it if they can't read their own e-mail.
