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
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.
--
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo