TSM does not use the NT Backup APIs; rather, it uses the Win32 File I/O
functions for accessing files.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Allan Kelly <KellyJA AT BCRAIL DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/02/2002 13:03
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Windows NTFS last accessed date set by TSM client



I was away for most of the past week and am just getting back to this
question now.  I passed the thread on to our NTFS guy because we are still
having problems with the last accessed date being set during TSM backup
scheduled runs on our file servers (these servers are virus protected with
CA's InoculateIT) and here is his response:

Hi - I work with Allan Kelly who started this thread.  I know next to
nothing about TSM, but am fairly well versed with Windows NT / 2000 / XP
and
I wanted to clear up a misconception I saw here.  Specifically, the idea
of
"accessing a file and then resetting the file's access time to it's
original
value".

It's true that the standard file APIs cause the file's access date to be
updated (at least the ones which open an individual file - there are also
directory scanning API functions which return information about files in a
directory such as file names, dates and basic attributes that don't change
the access dates of the individual files).  Since most programs use the
standard API functions, most programs update the "last access time" of
files
they touch.

However there's another set of file access API functions specifically
designed for backups and restores.  The actual function calls are
"BackupRead" and "BackupWrite".  These calls differ from the standard file
system API calls in the following ways:

They access even "hidden" file info such as security, multiple data
streams, and user-defined attributes.

They allow access by processes holding the Backup Operator privilege
even
to files that are protected against administrator access.

They don't update the file's "last accessed" timestamp.

The native NTBackup utility uses these API functions to back up and
restore
files.  TSM must use them too, since our tests show that it can back up
files that would otherwise be protected against it.

I'm no designer of virus scanning software, but it seems to me that it
would
make a lot of sense for a virus scanner to use the backup API functions
because it would need to make use of all of the extra functionality that
those functions provide (ie, access to protected files, access to normally
hidden data streams in the file, etc.).  Writing a virus scanner that
opens
files using the standard API and then going back and "fixing" the access
dates seems to me like a pretty silly design.

Since TSM appears to use the backup API functions, the question remains as
to why it updates the file access dates.  One possibility is that the
dates
are updated on the initial file scan pass when TSM is matching NTFS files
against files in the TSM database to see which files need to be backed up.
If the initial file scan pass opens the input files using the standard
file
API functions then it could explain this behaviour.

Sean Nelson
BC Rail Ltd.
North Vancouver BC
Canada

Thanks for any help.

Allan Kelly.