Hi Remy

Remy Lebeau (TeamB) wrote:


Great!!
Thanks.

Over the years I've had many files that I couldn't delete or rename and
I always thought it was because a program hadn't closed a handle, but you
are right (just tested ), så I guess there must have been another reason.

Thanks again
Best regards
Asger

Hi Jan

Jan Dijkstra wrote:


Are you using ::CreateFile ?
Because have seen ::CreateFile give ERROR_SHARING_VIOLATION where
there was no process using the file and when using FileCreate or
TFileStream everything worked fine.

https://support.microsoft.com/en-us/kb/316609

And I found this in another NG:

Check out the NET FILE command:

C:\>net help file
The syntax of this command is:

NET FILE
[id [/CLOSE]]

NET FILE closes a shared file and removes file locks. When used without
options, it lists the open files on a server. The listing includes the
identification number assigned to an open file, the pathname of the
file, the username, and the number of locks on the file.

This command works only on computers running the Server service.

id Is the identification number of the file.
/CLOSE Closes an open file and removes file locks. Type this command
from the server where the file is shared.

Best regards
Asger

Asger wrote:


TFileSteam internally uses FileCreate() and FileOpen(). Those functions
internally use CreateFile() on Windows.


ERROR_SHARING_VIOLATION can only happen if the file IS ALREADY OPEN when
you try to open it with access rights that are not compatible with existing
open handles to the file. That article says as much, as does the CreateFile()
documentation. AntiVirus and Backup systems are the usual suspects for this
behavior, but any process can potentially open any file for any reason.
You can't assume you have exclusive access to a file unless you have successfully
opened the file for exclusive access. Otherwise, it is fair game to anyone
with sufficient security rights.

--
Remy Lebeau (TeamB)