Re: Should rpm call umask(2)?

2007-07-11 Thread Russell Coker
On Wednesday 11 July 2007 09:07, Jeff Johnson [EMAIL PROTECTED] wrote: The sys-admin should be able to run rpm and have the packages   either correctly installed or the installation should abort.  There should be no other possible result. Even if the disk isn't spinning or is going click

Re: Should rpm call umask(2)?

2007-07-10 Thread Russell Coker
On Wednesday 11 July 2007 05:26, Jeff Johnson [EMAIL PROTECTED] wrote: But +1 for the 2 line hack noted. Another +1. The sys-admin should be able to run rpm and have the packages either correctly installed or the installation should abort. There should be no other possible result. --

Re: fsync()

2007-07-03 Thread Russell Coker
On Tuesday 03 July 2007 00:02, Michael Schroeder [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2007 at 08:02:40PM +1000, Russell Coker wrote: It's really a pity that people can't just write correct programs and that it needs to cost someone time and money and then more time fighting

Re: fsync()

2007-07-03 Thread Russell Coker
On Wednesday 04 July 2007 01:38, Jeff Johnson [EMAIL PROTECTED] wrote: The primary goal of package management is to install files reliably, not push the progress bars faster. Of course we could have a mode of operation for the initial system install that doesn't do the fsync(). The only time

Re: fsync()

2007-07-01 Thread Russell Coker
On Saturday 30 June 2007 19:52, Andy Green [EMAIL PROTECTED] wrote: Russell Coker wrote: On Saturday 30 June 2007 00:35, Andy Green [EMAIL PROTECTED] wrote: I don't think fsync() for individual files is really a fair answer, Why not? $ man fsync ... DESCRIPTION fsync

Re: fsync()

2007-06-30 Thread Russell Coker
On Saturday 30 June 2007 15:01, Wichmann, Mats D [EMAIL PROTECTED] wrote: OK/ fsync before close, todo++. Thanks for the info, xfs is a mystery to me. If you want to know any specific things about XFS then ask me. I'm currently working for SGI in a group that is associated with the

Re: fsync()

2007-06-29 Thread Russell Coker
On Friday 29 June 2007 05:37, Jeff Johnson [EMAIL PROTECTED] wrote: On Jun 28, 2007, at 2:28 AM, Russell Coker wrote: When upgrading a package with RPM version 4.4.2 in SUSE doesn't call fsync()! It creates a temporary file (without using O_SYNC), writes all the data to it, closes

Re: fsync()

2007-06-29 Thread Russell Coker
On Saturday 30 June 2007 00:35, Andy Green [EMAIL PROTECTED] wrote: I don't think fsync() for individual files is really a fair answer, Why not? it's fine if it just uses the normal filesystem APIs per-file.  But after the transaction is complete, and you walk away thinking you did complete

Re: fsync()

2007-06-29 Thread Russell Coker
On Saturday 30 June 2007 02:04, Jeff Johnson [EMAIL PROTECTED] wrote: Should I add O_SYNC when opening files on delayed write file systems? Doable, but annoying mapping the path back to a file system type to   infer functionality. O_SYNC is not the correct solution. XFS likes to delay block

Re: fsync()

2007-06-29 Thread Russell Coker
On Saturday 30 June 2007 12:02, Jeff Johnson [EMAIL PROTECTED] wrote: OK/ fsync before close, todo++. Thanks for the info, xfs is a mystery to me. If you want to know any specific things about XFS then ask me. I'm currently working for SGI in a group that is associated with the XFS group. I

fsync()

2007-06-28 Thread Russell Coker
When upgrading a package with RPM version 4.4.2 in SUSE doesn't call fsync()! It creates a temporary file (without using O_SYNC), writes all the data to it, closes it, and then renames it to replace the original file. Has this horrible mistake been fixed in the upstream tree? -- [EMAIL