Discussion:
[Fwd: [librsync-devel] bug 1110812 - 4Gigbug.patch does not work in Windows]
Sekar Vembu
2006-03-20 12:48:56 UTC
Permalink
Hi,
Subsequent to my original email, I think we have fixed the large file
problem in Windows too. We have made minor modifications to three files.
We have tested this and it seems to work for us. I am attaching the
three files with this email.
1. buf.c
2. librsync.h
3.PcBuild\librsync-config.h

The following are the cvs-diff for those three files. Hope some expert
will review this and check this in to the librsync CVS. If there is a
problem with these changes please let me know.

cvs diff buf.c
Index: buf.c
===================================================================
RCS file: /cvsroot/librsync/librsync/buf.c,v
retrieving revision 1.22
diff -r1.22 buf.c
209c209,215
< if (fseek(f, pos, SEEK_SET)) {
---
#if WIN32
if (_fseeki64(f, (__int64)pos, SEEK_SET) < 0 ) {
#else
if (fseek(f, pos, SEEK_SET)) {
#endif
cvs diff PCbuild\librsync-config.h
Index: PCbuild/librsync-config.h
===================================================================
RCS file: /cvsroot/librsync/librsync/PCbuild/librsync-config.h,v
retrieving revision 1.1
diff -r1.1 librsync-config.h
38c38,40
< typedef long rs_long_t;
---
typedef __int64 rs_long_t; //Modified type definition to __int64
from long



cvs diff librsync.h
Index: librsync.h
===================================================================
RCS file: /cvsroot/librsync/librsync/librsync.h,v
retrieving revision 1.5
diff -r1.5 librsync.h
54a55,58
int __cdecl _fseeki64(FILE *, __int64, int);
__int64 __cdecl _ftelli64(FILE *);
Regards,
Sekar





-------- Original Message --------
Subject: [librsync-devel] bug 1110812 - 4Gigbug.patch does not work in
Windows
Date: Mon, 20 Mar 2006 11:55:09 +0530
From: Sekar Vembu <***@vembu.com>
To: librsync-***@lists.sourceforge.net



Hi,
This is regarding the 4Gigbug.patch for the bug request id: 1110812.
This patch works well in Linux for file sizes more than 4GB. But the
large file problem (greater than 4GB) still exists in Windows. I think
here is what is happening.

The fseek in rs_file_copy_cb() method of buf.c still throws an error
when the seek is beyond 4GB. We tried changing the fseek to _lseeki64
and typedefinition of rs_long_t to __int64. But the problem is still
there. We do not know how to get fseek to work for large files (>4GB) in
Windows.

The error thrown in librsync while applying the delta is :

librsync: ERROR: (librsync) seek failed: Invalid argument
librsync: ERROR: (librsync) patch job failed: IO error

Can someone help with this.

Thanks
Sekar.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Donovan Baarda
2006-03-20 13:43:05 UTC
Permalink
Post by Sekar Vembu
Hi,
Subsequent to my original email, I think we have fixed the large file
problem in Windows too. We have made minor modifications to three files.
We have tested this and it seems to work for us. I am attaching the
three files with this email.
1. buf.c
2. librsync.h
3.PcBuild\librsync-config.h
The following are the cvs-diff for those three files. Hope some expert
will review this and check this in to the librsync CVS. If there is a
problem with these changes please let me know.
Please submit patches at the SF patch tracker...

Also, looking at this, I have a feeling this is compiler dependant,
rather than just WIN32 dependent. I suspect this stuff should be handled
by configure, rather than peppering the code with more #if WIN32 stuff.
Note that PCBuild/librsync-config.h should be auto-generated by running
configure with a MSC system.

In any case, thanks for this... if no one else gets around to it before
me, I'll look into it and see what the best approach for this is...
--
Donovan Baarda <***@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Sekar Vembu
2006-03-20 13:48:17 UTC
Permalink
Sorry about not using the SF patch tracker. We will learn the right way
to send patches in the future. Hopefully these fixes are useful and you
can incorporate it with the right approach in the librsync source code.

Thanks
Sekar
Post by Donovan Baarda
Post by Sekar Vembu
Hi,
Subsequent to my original email, I think we have fixed the large file
problem in Windows too. We have made minor modifications to three files.
We have tested this and it seems to work for us. I am attaching the
three files with this email.
1. buf.c
2. librsync.h
3.PcBuild\librsync-config.h
The following are the cvs-diff for those three files. Hope some expert
will review this and check this in to the librsync CVS. If there is a
problem with these changes please let me know.
Please submit patches at the SF patch tracker...
Also, looking at this, I have a feeling this is compiler dependant,
rather than just WIN32 dependent. I suspect this stuff should be handled
by configure, rather than peppering the code with more #if WIN32 stuff.
Note that PCBuild/librsync-config.h should be auto-generated by running
configure with a MSC system.
In any case, thanks for this... if no one else gets around to it before
me, I'll look into it and see what the best approach for this is...
Donovan Baarda
2006-03-20 13:59:15 UTC
Permalink
Post by Sekar Vembu
Sorry about not using the SF patch tracker. We will learn the right way
to send patches in the future. Hopefully these fixes are useful and you
can incorporate it with the right approach in the librsync source code.
Thanks... also, it is worth subscribing to the librsync-dev list on
SF... it means I don't have to keep approving your non-subscriber posts.

These fixes are definitely useful and will go in... the only thing yet
to be determined is how and when :-)
Post by Sekar Vembu
Thanks
Sekar
Post by Donovan Baarda
Post by Sekar Vembu
Hi,
Subsequent to my original email, I think we have fixed the large file
problem in Windows too. We have made minor modifications to three files.
We have tested this and it seems to work for us. I am attaching the
three files with this email.
1. buf.c
2. librsync.h
3.PcBuild\librsync-config.h
The following are the cvs-diff for those three files. Hope some expert
will review this and check this in to the librsync CVS. If there is a
problem with these changes please let me know.
Please submit patches at the SF patch tracker...
Also, looking at this, I have a feeling this is compiler dependant,
rather than just WIN32 dependent. I suspect this stuff should be handled
by configure, rather than peppering the code with more #if WIN32 stuff.
Note that PCBuild/librsync-config.h should be auto-generated by running
configure with a MSC system.
In any case, thanks for this... if no one else gets around to it before
me, I'll look into it and see what the best approach for this is...
--
Donovan Baarda <***@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Ben Escoto
2006-04-30 23:55:00 UTC
Permalink
Post by Sekar Vembu
wrote the following on Mon, 20 Mar 2006 19:18:17 +0530
Sorry about not using the SF patch tracker. We will learn the right way
to send patches in the future. Hopefully these fixes are useful and you
can incorporate it with the right approach in the librsync source code.
Yes, I for one am ecstatic that someone seems to have finally tracked
down the 4Gb+ bug. People post about this from time to time on the
rdiff-backup list and it's not clear if it's librsync or not, and the
probably only occurs sometimes.

So, if you fixed it, great work! :-)
--
Ben Escoto
Loading...