[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#561880: marked as done (inotify/hppa: Not assigning sequential ids as expected)



Your message dated Thu, 24 Dec 2009 13:19:41 -0800
with message-id <20091224211941.GA16859@jade.home>
and subject line Re: Bug#561880: linux-image-2.6-parisc64: inotify_add_watch does not give a unique watch descriptor
has caused the Debian Bug report #561880,
regarding inotify/hppa: Not assigning sequential ids as expected
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
561880: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561880
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-2.6-parisc64
Severity: important
Blocks: 558981

The attatched minimal test case shows these results:

on my i386 machine, it correctly gives two different numbers:
$ gcc test.c; ./a.out
First: 1
Second: 2

however on paer.debian.org (hppa):
$ gcc test.c; ./a.out
First: 1
Second: 1

Based on the manpage of inotify_add_watch, it sounds like the correct
behavior is to have different numbers. It seems that the author of
inotify-tools also interpreted it that way.

This bug is causing my package's tests to fail, which causes it to FTBFS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558981

Cheers,
Ryan

-- 
_________________________
Ryan Niebur
ryanryan52@gmail.com
#include <sys/inotify.h>
#include <stdio.h>

int main()
{
    int fd, wd;

    fd = inotify_init ();
    wd = inotify_add_watch (fd,
                            "test.c",
                            IN_OPEN | IN_CLOSE);
    printf("First: %d\n", wd);
    inotify_rm_watch(fd, wd);
    wd = inotify_add_watch (fd,
                            "a.out",
                            IN_OPEN | IN_CLOSE);
    printf("Second: %d\n", wd);
    inotify_rm_watch(fd, wd);
}

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message ---
On Mon, Dec 21, 2009 at 01:02:14AM +0000, Ben Hutchings wrote:
> On Sun, 2009-12-20 at 16:35 -0800, Ryan Niebur wrote:
> > Hi Ben,
> > 
> > thanks for the response.
> > 
> > On Mon, Dec 21, 2009 at 12:12:44AM +0000, Ben Hutchings wrote:
> > > On Sun, 2009-12-20 at 15:46 -0800, Ryan Niebur wrote:
> > > > Package: linux-image-2.6-parisc64
> > > 
> > > Yes but which version?
> > > 
> > 
> > the version that paer is running (apparently
> > linux-image-2.6.32-trunk-parisc64 2.6.32-1)
> 
> Wow, already?  OK.
> 
> > and whatever version peri is running.
> > 
> > > > Severity: important
> > > > Blocks: 558981
> > > > 
> > > > The attatched minimal test case shows these results:
> > > > 
> > > > on my i386 machine, it correctly gives two different numbers:
> > > > $ gcc test.c; ./a.out
> > > > First: 1
> > > > Second: 2
> > > > 
> > > > however on paer.debian.org (hppa):
> > > > $ gcc test.c; ./a.out
> > > > First: 1
> > > > Second: 1
> > > > 
> > > > Based on the manpage of inotify_add_watch, it sounds like the correct
> > > > behavior is to have different numbers. It seems that the author of
> > > > inotify-tools also interpreted it that way.
> > > > 
> > > > This bug is causing my package's tests to fail, which causes it to FTBFS:
> > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558981
> > > 
> > > I think the test case is broken; why should two watches that don't exist
> > > at the same time have unique ids?  You might as well test:
> > > 
> > 
> > the manpage makes it sound like it should be unique for each
> > filename. and if the test case is broken, then I don't understand why
> > this only fails on hppa.
> 
> I'm saying there is no guarantee in the manual page about what order
> watch ids will be assigned in, and that it is unreasonable to expect
> "unique" to mean "unique among all watches that ever existed for this
> handle".  The assignments could vary depending on the architecture or on
> the phase of the moon.  The test cases should not make any assertions
> about them, other than that any two watches *that exist at the same
> time* have different ids.
> 
> However, it does look like the implementation is intended to assign
> sequential ids, so this may indicate a bug in the implementation.  But
> it shouldn't block you.
> 

okay, thanks, I'll correct the tests.

Cheers,
Ryan

-- 
_________________________
Ryan Niebur
ryanryan52@gmail.com

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply to: