On Thursday 03 May 2007 17:16, Brian Debelius wrote: > Kern Sibbald wrote: > > On Thursday 03 May 2007 01:12, Doug Rintoul wrote: > > > >> Kern Sibbald wrote: > >> i.e. it didn't work once :( > >> > >>> Disappointing but not too surprising. The good news is that since the > >>> > > error > > > >>> message is different from before, it shows that it is really my code that > >>> > > is > > > >>> being executed, which is definitely a step forward. Also, once it fails > >>> > > in > > > >>> this way, it is to be expected that it will fail on all truncates. > >>> > >>> Apparently, the old Bacula code was never "cleaned" up after the > >>> > > conversion to > > > >>> mingw, which means I got confused on how to deal with the file handle > >>> > > (there > > > >>> are two different conventions). This means the current failure is most > >>> likely that I am passing a bad file handle to the Win32 API. > >>> > >>> I have "corrected" the bad file handle problem (hopefully) and posted the > >>> > > new > > > >>> binaries to my web site in the same location (see above from my previous > >>> email). The name of the binary is the same, but the Bacula build date is > >>> > > 02 > > > >>> May. > >>> > >>> Please try this version. If nothing else, in the case of a failure, it > >>> > > should > > > >>> give us a true Win32 error message rather than just "Permission denied". > >>> > >>> Thanks for the quick testing. By the way, if it fails this time, I will > >>> > > need > > > >>> to do significantly more research to fix the problem, but I can as a > >>> temporary measure implement two "kludges", which I have not yet done: 1. > >>> > > make > > > >>> it use the old code for the less than 2GB case. 2. Ignore any errors. > >>> > >>> > >> Seems to be working for me here. As with the others, the older 2.0.4 > >> failed for all backups. This new version has worked for me even when the > >> original volume was greater than 2 gigs. > >> > > > > OK, nice. I'm glad the problem is fixed. I'm sorry it wasn't resolved > > quicker. Thanks for the testing and the feedback. > > > > Regards, > > > > Kern > > > > > >> Doug Rintoul. > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> _______________________________________________ > >> Bacula-devel mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/bacula-devel > >> > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > Im just curious as to what the problem was.
The Microsoft crt dll (POSIX compatibility layer) apparently doesn't handle files greater than 2GB in the _chsize() function (their equivalent to ftruncate). I guess they use an old 32 bit lseek rather than the newer 64 bit lseek. I wrote my own win32_ftruncate() which is only about 10 lines of code. > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
