We are in the process of writing an Linux archive client through
the TSM API (4.2), storing objects in an TSM 4.1 server running
on AIX. We would like to avoid writing a retrieve client, as
we're satisfied with the functionality of the TSM BA client. I
know there have been interoperability issues in the past, but the
API manual clearly addresses *some* of these issues.
What we are wondering is how file permissions need to be stored
by the API client so that the BA client can retrieve them
properly.
We attempted to pass a struct stat in the objAttrPtr.objInfo
(see below), but when we retrieve the files using the BA client,
all files are retrieved with perms set to 000 and a timestamp
that is very wrong (e.g. Dec 5, 1930 on some files :-), rather
than the perms and timestamp stored in the struct stat.
This was just a guess (which was apparently wrong), but it's
completely unclear as to what *would* be correct. Page 74 of the
API Manual states the following in reference to using
restore/retrieve commands for API objects:
Note: Use these commands for exception situations only.
These commands return data as bit files that are created
using default file attributes. You can restore or retrieve API
objects that other users own, or that are from a different
node. The set access command determines which objects qualify.
If it were truly using "default" file attributes, I would have
expected them to be umask based. But the fact that perms are set
to 0 and the timestamps are set consistently wrong indicates that
the BA client *is* attempting to use the struct stat info in
objInfo.
Has anybody reconciled this? Has anybody successfully written an
API client for which objects can be retrieved or restored using
the BA client?
Thanks,
-- Tom
Thomas A. La Porte
DreamWorks SKG
[EMAIL PROTECTED]
if ((rc = lstat(filelist[i].filename, &sb)) != 0)
{
fprintf(stderr, "stat %s: ", filelist[i].filename);
perror("");
continue;
}
[...]
ObjAttrData.objInfoLength = sizeof(sb);
ObjAttrData.objInfo = (char *)&sb
