We're all right, but not shedding a lot of light at this point. I hope Nick finds a solution to his original problem.
Lindsay Morris Principal TSMworks Tel. 1-859-539-9900 lind...@tsmworks.com On Wed, Jan 6, 2010 at 7:08 AM, Schaub, Steve <steve_sch...@bcbst.com>wrote: > While we're "quibbling"... > What I would like is a single install binary that I could throw at W2K3, > W2K8, x86, x64 and have it automatically detect and install what it needs, > rather than me having to create multiple install scripts. While we're at > it, having a central console to "push" new clients out in mass would be nice > too. > > Steve Schaub > Systems Engineer, Windows > BlueCross BlueShield of Tennessee > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of > Wanda Prather > Sent: Tuesday, January 05, 2010 9:37 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Disparate Client Options > > > I could quibble - they have to do all that anyway, right, across the > > various > > clients? > > > > I don't think so. Consider, how would you map an ACL for a UNIX file in > say, an AIX DFS filesystem, to an ACL for a Windows file system? The > client > is supposed to honor those ACL's, and restore them along with the data. I > don't see how that would work. > > And you can have things in non-text files that simply don't compute when > moved from UNIX to Windows and vice-versa. Moving a binary from UNIX to > Windows won't make it executeable. And there are file formats that have > big-endian vs. little-endian issues (for example, output from Fortran, for > which there were UNIX compilers at one time, although I realize there are > fewer and fewer such cases these days.). > > And Richard is correct, when restoring to Windows, TSM doesn't write the > files; it calls NTFS to write the files. I don't know that all the > filesystem calls translate. For instance, you can create an empty 2GB file > in an NTFS filesystem; there is no such thing in a JFS. > > And there are at least 5 different filesystem types for AIX, at least 4 > that > I know of for Red Hat, et cetera, et cetera.... many, many permutations. > > SO if you say well those aren't the files I'm interested in, I just want > flat files...then I think what you are looking for is a different protocol > altogether - maybe ask for a "bit stream restore", where TSM will restore > the bits into a flat file across operating systems, ignoring all the > conversion issues, and make you responsible for decoding the result. > > But I'm still not sure that's desirable from a security point of view, and > most people will find it less work to restore the file back to its original > O/S and FTP it, thereby taking the responsibility of stripping out the > ACL's > themselves... > > W > > > > > Lindsay Morris > > Principal > > TSMworks > > Tel. 1-859-539-9900 > > lind...@tsmworks.com > > > > > > On Tue, Jan 5, 2010 at 2:22 PM, Richard Sims <r...@bu.edu> wrote: > > > > > On Jan 5, 2010, at 12:19 PM, Lindsay Morris wrote: > > > > > > > True, unix to unix works, and windows to windows too. Osx and netware > > are > > > oddballs, but not so common. > > > > > > > > But we build an appliance that wants to "dsmc restore" from ALL the > > nodes > > > on a TSM site, windows and unix both, to spot-check recoverability. > Dsmc > > > blocks cross-platfrm restores (windows vs unix at leadt), and for no > good > > > reason, AFAIK. > > > > > > Well...consider what's involved. The good reason is that a fully > > > cross-platform client architecture would have to include full > programming > > > for the universe of file system types accommodated on all the supported > > > platforms - and additionally would have to adeptly provide a meta layer > > of > > > emulation of the wealth of system calls associated with the file system > > > which is not native to the receiving platform. That's an enormous > amount > > of > > > development and testing and maintenance. I'd rather that their > energies > > > went toward things like 64-bit clients, and administrative API, and > > > long-overdue evolution of the terribly neglected CLI. > > > > > > Richard Sims > > > > > > > ----------------------------------------------------- > Please see the following link for the BlueCross BlueShield of Tennessee > E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm >
