An unusual occurrence leading to a Btrieve status code 20 ("Record manager inactive") occurred to a user of an older version of the Btrieve engine recently. In troubleshooting the error and clicking on the legacy Microkernel engine, we received the dreaded "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
Yet users did have permission. Curiously though for this one (critical) record manager engine file, Windows could not show the security and required elevated access (which it already had). Then it showed group access and ownership erratically, sometimes as expected, sometimes not. And when trying to take ownership and establishing security levels, permissions could not be saved.
Trying to run the w32mkde.exe from a command prompt gave the message "Access denied" leading us to suspect that there were open sessions.
After closing all of the three running sessions that had a number of files open including the w32mkde.exe, that file was then literally . . . . . gone. Vanished. Poof. It alone had to be reinstalled/copied into the software folder.
We've seen this behavior before: something (or someone) tries to delete a file but can't because it is open. Then when the session is closed that has that file open, the operating system then, on a delayed basis, deletes the file. But if the file is being denied access and appears to still exist, why is it deleted later? And we've seen this happen with other executables as well when we have tried to remove them after not realizing they were open.
Sometimes this message can indicate that the file is blocked and needs to be unblocked. That was also not however the case here.
The situation here in fact involves a "shared delete" described here under SMB file locking:
https://docs.microsoft.com/en-us/rest/api/storageservices/managing-file-locks
"Shared delete: Allows subsequent deleting of a file. If this flag is not specified, any request to delete the file will fail until the file is closed."
So a currently open file that has a sharing violation can be flagged for deletion if an attempt is made to delete it while that file is open (e.g. at a cmd prompt: DEL SOMEFILE.EXE). The file will appear to exist (since it actually still does) but if run (in the case of an executable) the operating system will respond with "Access denied" and then when the processes or user sessions that had file open are closed, the file will be gone.
The same exact situation can be duplicated with other types of files that are open and if an attempt is made to delete them while open. This behavior is not unique to "server" class PC's.
This scenario is very different than situations where users receive an "access denied" response or "Windows cannot access the specified device" due to permission or other issues. In this case, we do not know what had triggered the attempt to delete the w32mkde.exe in the first place.
Additional information:
Process Explorer (part of Windows Sysinternals, so it is a free download) can tell you which program has a particular or directory open and is available for Windows Vista and above:
https://technet.microsoft.com/en-us/sysinternals/bb896653
In terms of who has a file open on a PC network, we typically use compmgmt.msc (then Shared Folders and then Open Files). However that approach alone will not necessarily identify all open files nor therefore necessarily be able to close all files that may be open (for example, on Pervasive systems, the Pervasive monitor is needed to see open data files and to close them; and so related files/sessions should not be closed via compmgmt.msc until using the monitor utility on applicable systems to verify that a given user's data files are not open and/or to close them).
No comments:
Post a Comment