Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 3 Oct 2001 13:45:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 3 Oct 2001 13:45:35 -0400 Received: from quechua.inka.de ([212.227.14.2]:2361 "EHLO mail.inka.de") by vger.kernel.org with ESMTP id ; Wed, 3 Oct 2001 13:45:28 -0400 From: Bernd Eckenfels To: linux-kernel@vger.kernel.org Subject: Re: Finegrained a/c/mtime was Re: Directory notification problem In-Reply-To: X-Newsgroups: ka.lists.linux.kernel User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.4.10-xfs (i686)) Message-Id: Date: Wed, 03 Oct 2001 19:45:55 +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Alex Larsson writes: >> I discovered a problem with the dnotify API while fixing a FAM bug today. >> >> The problem occurs when you want to watch a file in a directory, and that >> file is changed several times in the same second. When I get the directory >> notify signal on the directory I need to stat the file to see if the >> change was actually in the file. If the file already changed in the >> current second the stat() result will be identical to the previous stat() >> call, since the resolution of mtime and ctime is one second. If you simply check the mtime and the file size you have the two most relevant parts. If neighter of those changes this means that programs using the dnotify api most likely do not need to act. After all it is not an auditing facility but a notifier for things like reload of directory listings. The only thing I could imagine can cause problems is a self reloading config file. But in that case dnotify is overkill anyway and a 1 sec delay could be asumed to be reasonable. Greetigs Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/