fam
[Top] [All Lists]

Re: [fam] Fam race condition

To: alexl@xxxxxxxxxx, fam@xxxxxxxxxxx
To: Alex Larsson <alexl@xxxxxxxxxx>
Subject: Re: [fam] Fam race condition
From: raster@xxxxxxxxxxxxx
From: Carsten Haitzler (The Rasterman) <raster@xxxxxxxxxxxxx>
Date: Wed, 3 Oct 2001 09:21:10 +1000
Cc: fam@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.33.0110021623360.16409-100000@xxxxxxxxxxxxxxxxxxxxxxxx>
Organization: You expect me to be organized?
References: <Pine.LNX.4.33.0110021623360.16409-100000@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-fam@xxxxxxxxxxx
On Tue, 2 Oct 2001 16:30:51 -0400 (EDT) Alex Larsson <alexl@xxxxxxxxxx> babbled
profusely:

> I found a pretty bad race condition in fam.
> If several changes are made to one file in the same second, fam will only 
> report the first one. It does not detect the following ones, because the 
> resolution of ctime (used to see if the file changed) is only one second.
> 
> This patch partly fixes the problem:
> 
> --- fam-oss-2.6.4-alex/fam/Interest.c++.race  Tue Oct  2 16:05:45 2001
> +++ fam-oss-2.6.4-alex/fam/Interest.c++       Tue Oct  2 16:14:12 2001
> @@ -181,7 +181,13 @@
>  
>      bool exists = status.st_mode != 0;
>      bool did_exist = old_stat.st_mode != 0;
> -    bool stat_changed = old_stat.st_ctime != status.st_ctime;
> +    bool stat_changed =
> +      (old_stat.st_ctime != status.st_ctime) ||
> +      (old_stat.st_mode != status.st_mode) ||
> +      (old_stat.st_uid != status.st_uid) ||
> +      (old_stat.st_gid != status.st_gid) ||
> +      (old_stat.st_size != status.st_size) ||
> +      (old_stat.st_ino != status.st_ino);
>      old_stat = status;
>      
>      if (exists && !did_exist)
> 
> But it is still broken if parts of the file contents are rewritten during 
> the second. I see no way to fix this except delaying change notifications 
> until the end of the second. That sort of breaks the reason for fam 
> though, so i didn't do that.
> 
> How did sgi never notice this? They've shipped fam forever. Don't they 
> ever test their software?

likely they havent heavily tested the "polling" mode - and rely on the kernel
layer (imon) to do the work. i think they assume you knwo that polling mode isnt
100% reliable (could miss a file appear and dissapear if it does it between
polls and more) so it wan't an issue to look into.

at least that's what i assume was the case :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@xxxxxxxxxxxxx
Unemployed Bum                      raster@xxxxxxxxxxxxxxxx
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>