Re: ANE4007E - Access is denied
The exclusive "lock" derives from the share mode specified at the time the
locking application opens the file. If the application opens the file with
all sharing modes disabled, then nothing else can open the file for any
access, even read-only, until the application closes the file. For example,
the Win32 API function CreateFile() allows you to specify a share mode of 0
(zero), which means no sharing at all. If your app opens a file with
CreateFile() and specifies a share mode of 0, any subsequent attempts to
open the file will fail until your app calls CloseHandle() to close the
I don't know of any means to circumvent this without the help of some kind
of open file manager (OFM) software. My guess, then, would be that
a) Just skips the file. You can do this with TSM as well be coding an
EXCLUDE statement for it in the client options file.
b) Uses some kind of open file manager, either their own or someone else's.
The OFM software from St. Bernard (www.stbernard.com) is fairly popular, or
so I believe. Perhaps if there are any folks on this forum that use an OFM,
they can share (no pun intended) their experiences.
Tivoli Storage Manager Client Development
e-mail: andrew.raibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
"Kelly J. Lipp" <lipp AT storsol DOT com> on 11/30/2000 10:22:44
Please respond to lipp AT storsol DOT com
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Andrew Raibeck/Tivoli Systems)
Subject: Re: ANE4007E - Access is denied
How in the world does Veritas do this? And if they can back the darn
up can they actually restore them?
I believe this occurs because the application takes an exclusive lock on
file. This must mean that Veritas does not check the lock before opening
Perhaps the client coders can tell us how this works and speculate on what
Veritas is doing.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
Fax: (719) 260-5991
Email: lipp AT storsol DOT com