public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Padraig Brady <padraig@antefacto.com>
To: Alex Larsson <alexl@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Directory notification problem
Date: Wed, 03 Oct 2001 12:49:57 +0100	[thread overview]
Message-ID: <3BBAFB65.6070802@antefacto.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0110022206100.29931-100000@devserv.devel.redhat.com>

I think if you want better than 1s resolution you need to
handle it in user space. I've done this using 2 methods
outlined below. This first may be more responsive for
your app, though depending on the processing you have
to do on each file it may be too great an overhead to
process things twice, and if you want to process the data
multiple times within a second then you're screwed (you
probably don't want to do this from what I understand?).

A generation counter like you suggest would be very nice though!

Padraig.

/////////////////////////////////////////////////
// Delayed processing method
/////////////////////////////////////////////////
struct file_data
{
    char* name;
    time_t last_mtime;
    long generation_count; //wouldn't this be nice ;-)
}

bool filechanged(const file_data* file)
{
    struct stat stat_st;
    bool modified = false;

    if (!stat(file->name, &stat_st)) {
        if (stat_st.st_mtime != file->last_mtime) {
            modified = true;
            file->last_mtime = stat_st.st_mtime;
            sleep(1); //make sure any new updates in this mtime processed.
        }
    }
    return modified;
}
/////////////////////////////////////////////////
// Double check method
/////////////////////////////////////////////////
struct file_data
{
    char* name;
    time_t last_mtime;
    bool secondRun = false;
    long generation_count; //wouldn't this be nice ;-)
}

bool filechanged(const file_data* file)
{
    struct stat stat_st;
    bool modified = false;

    if (!stat(file->name, &stat_st)) {
        if ((stat_st.st_mtime != file->last_mtime) || (file->secondRun 
== true)) {
            modified = true;
            /* make sure don't miss data for this mtime (1 second 
resolution).
               Will do redundant check if no data written between now 
and next check
               but at least no new data will go unnoticed. Note this 
function must be called
               at a resolution >= 1 second for this to work. */

            if (file->last_mtime != stat_st.st_mtime) {
                    file->last_mtime = stat_st.st_mtime;
                    file->secondRun = true; //reset
            } else {
                    file->secondRun = false;
            }
        }
    }
    return modified;
}

Alex Larsson wrote:

>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. 
>
>This leads to missed notifications, leaving clients (such as Nautilus or 
>Konqueror) displaying an state not representing the current state.
>
>The only userspace solutions I see is to delay all change notifications to 
>the end of the second, so that clients always read the correct state. This 
>is somewhat countrary to the idea of FAM though, as it does not give 
>instant feedback.
>
>Is there any possibility of extending struct stat with a generation 
>counter? Or is there another solution to this problem?
>
>/ Alex
>
>Please CC any reply to me, i'm not on the list.
>




  reply	other threads:[~2001-10-03 11:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-03  2:18 Directory notification problem Alex Larsson
2001-10-03 11:49 ` Padraig Brady [this message]
2001-10-05 19:18 ` Pavel Machek
2001-10-05 21:08   ` Alex Larsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BBAFB65.6070802@antefacto.com \
    --to=padraig@antefacto.com \
    --cc=alexl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox