On Wed, Nov 05, 2003 at 02:36:46PM +0100, JC Simonetti wrote: > On Wed, 5 Nov 2003 04:52:33 -0800 > David Wolfskill <[EMAIL PROTECTED]> wrote:
> > I wasn't aware that the Win32 environment was sufficiently "special" > > that tar archives were unportable between that and normal (UNIX) > > environments. > It's the reason of the existence of the WinTar software :) Oh. I had (perhaps naively) thought that it was merely a win32/NT/...? port of a more standard tar.... > > Well, I suppose it might be, if it were small enough to fit in the > > available space on the Windows box, and if someone who had a clue about > > the Windows environment (i.e., not me) did it. But it's a (Win32) tar > > archive for the entire "C:" drive. > Whoops... Try a smaller tar to make your tests... Well, I suppose any sub-tree would be somewhat smaller, but I have no idea how Microsoft spells "du". > I did not use amrecover for my restorations, but just amrestore. Why? Because in my > backup architecture, I d not want to restore to data directly on the client but I > restore them on the backup server then push them on the client. > And as WinTar and GnuTar are different, I was just able to extract the dd image from > the tape with amrestore and push these data on the Win32 server, and over there > untar them. > But I was backing up small data, something les than 5 Gb, so I was able to have on > my Windows box the tar and the untar data simultaneously, right :) Ah. Well, nearly anything that is done around here involving a Microsoft platform will need to be done by someone other than me: they seem to be remarkably unreliable around me. (They probably know what I think of them....) > Concerning development on Win32 architectures, you have Dev-C++ > (http://sourceforge.net/projects/dev-cpp/) : a free software IDE compiler under > Windows. Well, for whoever does the development, that might be useful; thanks. > Personally I don't like the Win32 client since it is based on a CVS snapshot of > Amanda from august 2001 : so old isn't it?! Understood. I believe that my employer would be willing to pay someone to re-do that work, with a more recent version of the source. > Maybe a future development of this client should only be libraries to interface the > *nix version of Amanda under Win32, maybe real libraries or patches to apply on the > sources, but something that would be generic and not applied on a particular version > and just on this version. Maybe in the longer term; for now, we just want something that actually works. > The 2 other solutions are : > 1. Samba backup using "smbclient" on the Linux Amanda server: simple but you do not > backup NT file rights (well... see some messages above in the mailing-list, someone > sent a little script to backup the rights) Yes, I know of this. However, in our environment, it is not an acceptable approach. > 2. Cygwin and the Amanda source code: very functional but you have to install a > Linux emulator on your Windows box... I don't like the idea (what would you say if I > told you that you have to install a Windows emulator on your BSD to backup your BSD?) Right; I expect that Cygwin will be involved, but only for development. We are trying to minimize the impact on clients' machines. Thanks again, david -- David H. Wolfskill [EMAIL PROTECTED]
