Hello, On Wednesday 13 December 2006 10:11, Oliver Lehmann wrote: > Hi Kern, > > Kern Sibbald writes: > > > 1. They are not relative to the current CVS. > > Hm, they are applying to it, or? At least I tried that.. > > > 2. They are a significant change from the current code, which is not a problem > > during the development cycle, but *is* a major problem at this point. > > This I understand and I agree fully here. when 1.40 is at the end of the > release cycle this change is too sweeping to include. But maybe for a later > release it is ok. For so long it can be kept as local patches... > > > > 3. They seem to change non-FreeBSD code -- perhaps not the functionality but > > by adding a switch(). > > If that is a problem, it can also be done by using if() but I found switch() > more suitable here. > > > On the other hand, I would suggest that you work with Jeremy Reed as his patch > > once it is appropriately tweaked is something that I could see adding to 1.40 > > because: > > 1. It is relative to the CVS > > 2. It makes the mininum necessary changes > > 3. For the most part the changes seem to be FreeBSD specific > > patch-src-findlib-create_file.c is based on his patch. I just added the > restore of the file flags on failure, and error messages in case of > failures. What is the problem with it and the CVS version?
I would like to put in a fix for the hardlink failure problem and possibly for the attiributes update errors problem, but I need as I said before: 1. A simple patch (or two if you want) that is the absolute minimal change and if at all possible modifies only FreeBSD code. 2. The diff must be done against the current CVS not against a file named xxx.orig which I have no idea where it came from or what version it is. Look at Jeremy Reed's diff, you will see that it is done against the cvs and thus packed with all kinds of additional information that I need. You may feel that I am being a bit picky here, which is probably the case, but this is documented in the Developer's manual and *really* helps to make communication of patch files and their integration *much* more smooth and sure. 3. A really minor point is that the patch should be an attachment (as you did), but it should be named xxx.patch e.g. chflag.patch or findlib-attribs.patch or create_file.patch. What you are sending me is not a .c file, so shouldn't be named that way. It makes reading it harder -- since then my email reader knows what the content is and calls the correct viewing program when I open it. Regards, Kern > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
