On Mon, 2004-01-05 at 16:13, David Kempe wrote:
Greg Freemyer wrote:
Great work. I assume you are saying that you have a pure win32 version
working. ie. No use of the cygwin dll.
sorry Greg, I just couldn't get that to work.
the c files for rdiff-backup gave me the same errors that I posted with
mingw32 with Visual Studio 6. Looks like they only compile with gcc from
cygwin or linux. and I tried your suggestion of compiling them with the
gcc from cygwin with the right flags, it (the .o file) compiles with
warnings, but then gives heaps more erros when you go onto the .dll.
So I gave up on that and worked on paring back the cygwin version to as
small as possible. this is merely a result of that. sorry, I'm not that
brilliant at c to make it work :(
That is definately a difficult task. Hopefully someone will do it
someday, but like you I don't have the resources to attack it right now.
A couple questions:
Are you using a native win32 /bin/sh, or a cygwin one?
cygwin /bin/sh.exe
Not a problem since you have cygwin.dll around anyway.
What python are you using (win32 or cygwin)?
cywin.
Hopefully this is a relatively recently released version. Cygwin.dll
1.5.x was released this summer and it was a major upgrade that added 2
GB+ file support. All cygwin apps (i.e. python itself) had to be
recompiled to use the new functionality.
Do you need the cygwin.dll installed at all on the installation
computer?
yes, but my setup.exe looks after that, and there should be no conflicts
with existing setups (except for the outlined /bin/sh problem) as its
all stored in its own self contained folder.
That sounds good. Since cygwin is not really a release, but more a
collection of random projects, I never have understood how they do QA.
ie. New cygwin versions of projects get released all the time, but how
do you know what cygwin.dll's they work with.
What is the status of backing up:
Large files (over 2 GB used to be a problem in cygwin)
I haven't tested - would you like a copy to test? (mail me off list and
I will send you a link.) I haven't included any documentation or
licensing yet as its still in development, so I am reluctant to release
it to the world without at least a copy of the GPL :)
If the installation is fairly straight-forward, I would like to give it
a whirl. Just e-mail me directly with the link.
FYI: If you used a 1.5.x version of cygwin, and a python compiled
against that, then the 2 GB limit should be gone.
If not, appropriate versions of both are now in the stable cygwin setup
branch I believe.
ACLs (Access Control Lists)
according to
http://pylibacl.sourceforge.net/ the pylibacl module
doesn't support cygwin.
previously when I was using cygwin ssh and not plink I had a problem
where if your cygwin install didn't pick up on the permissions properly,
ssh couldn't determine the owner of the ssh keys and refused to use
them. On a FAT32 partition this was pretty impossible to get around. It
is possible with a cygwin variable, but that didn't work as we have a
Samba domain controller, which didn't mix well with it. So strangely
enough I have to use plink because of samba :)
Anyway, pylibacl support aside, I think that ACL/permission support in
cygwin is dodgy enough as to be a problem for many people. rdiff-backup
would need a native win32 acl module I would have thought.
Unfortunately, I agree. That is one of the reasons I did not pursue a
cygwin version very hard. ACL support is not even released in the main
code yet,
One way to make this work may be to write a win32 native C dll that
interfaces to the win32 acl api, then connect to that from rdiff-backup.
I may look into trying to do that at some point.
Open files (Most commercial packages use Open File Manager from St.
Bernard to make this work. It can be configured for random backup
programs, but I have never tried to configure it before.)
I did ask them. Basically, OFM works by detecting an SMB using accessing
shares, then provides something very similar to the WIN2K3 shadow copy
to that user.
Now that would be an interesting project. i.e. Getting rdiff-backup to
work with Win2k3 shadow copy (VSS). I really like the way VSS is
structured. (I haven't used it yet, so I don't know how well it is
implemented.)
At around AU$900 for a license, its not something I am
going to go for - stopping the services is easy enough and I don't know
a client that can't afford to not have exchange/mssql stopped for an
hour or so each night. You might be different. Alternatively, both those
programs have backup/deleted items retaining setups, so you can get
around it that way.
Yes, it is expensive. I'm always surprised they don't have a major
competitor. I guess Microsoft got tired of seeing them making all that
money, thus VSS.
for exchange I just set the deleted items retention to 30days and stop
the service and back it up. rdiff-backup can't do diffs on the database,
so you can't do it very often unless you have a large disk (I use
firewire).
MSSQL can be configured to do dumps of its database pretty often, so you
can back up the dumps with rdiff-backup.
As for other abitrary files, there is no reason why OFM wouldn't work,
but it just relies on that smb user login method to tell when to offer
the open files.
Congratulations on your success. I tried a get pure win32 version about
a year ago and gave up, so I know it was not a trivial effort.
A pure win32 version would that some rewriting of rdiff-backup I am not
prepared to undertake. Especially since the cygwin version just has the
same license and the installer is only 2.3meg.
Understood.
BTW: it would be great if you could put the above info on the wiki.
I'll try get to that this afternoon :)
dave
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://mail.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
