I don't test with inotify since it is not yet in the kernel tree.
You will have to check with the inotify developpers or the distro
support which ships with inotify.

Daniel

Daniel, 

You test it with dnotify? does it work with dnotify all right?
rlove still thinks it's a gamin problem, maybe John McCutchan can test it and
comment?

Hi, I'm having this same problem - gnome will not pop up an icon for my usb hdd
when i plug it in during a session. This problem only occurs when I use a
combination of gamin and inotify. I have tested the dnotify backend by removing
user permissions from the inotify device node - the problem dissappears. The
problem, then, lies either with inotify itself or the gamin inotify backend.

In fact, since fairly recently (perhaps the inotify abi change) file monitoring
(with gnome at least) using gamin and inotify does not seem to work at all (use
terminal to delete a file/dir while watching the containing dir with nautilus).

interesting. I am using gamin-0.0.26 with inotify-0.20 and everything works fine
so far except the automount icon. 
Who can help out verify what's the problem with inotify or gamin's inotify backend?
I spoke to rml on irc and he said it can't be inotify, and that John McCutchan
might help as he's the one responsible for gamin's inotify backend. But I dunno
where to contact him...

Gamin cvs with inotify 0.21 is where I'm having problems. Possibly the patch
updating the inotify backend to the new inotify abi is bad.

I'm using now gamin-0.0.26 with cvs patch for inotify-0.21 and it works OK, but
this problem is still present as in inotify-0.20.

This bug is not present with the dnotify/polling backend, but is present with
gamin 0.0.26 + inotify patch using inotify on kernel 2.6.11. This is on a Gentoo
system with GNOME 2.10.

With kernel 2.6.12-rc1-bk3 and the latest inotify v0.21, gamin cvs, the test
suite fails on all but test 1 - no expected results show at all. With the
inotify devnode 'disabled' all tests seem to at least give results. 
Note I am also using the time-sliced cfq iosched from mm, but the drive is using
the AS scheduler in these tests.

I bumped into the same problem when I updated to the 2.6.12-rc kernel. I opened
the bug on gnome-vfs thinking it was their bug. But after testing without
inotify it was obvious this is a gamin bug.

The inotify API changed in the newer kernel versions, and the patch that was on
the gamin mailing list, tried to fix that, but wasn't enough.

I found another patch on the gentoo bugzilla, which fixed nautilus's file
monitoring, so files appeared as they were created and disappeared when removed.

http://bugs.gentoo.org/show_bug.cgi?id=86705

But it didn't fix, the device hotplug thing. gnome-volume-manager would mount
and browse the media normally, but the icon wouldn't appear on the desktop and
in computer:// 
Only when you mount or unmount anything else in computer would it update itself. 

Please fix the inotify backend, it's supposed to replace dnotify I think..

Hey, I just spotted this bug. Gamin's inotify backend barely works. It was
really just a proof of concept. Gamin's backend design isn't great, because for
the inotify backend to work properly, it needs to mimic the dnotify backend
logic exactly. Which means an intricate use of the poll backend in combination
with inotify. 

Once my exams are finished, I plan on fixing the inotify backend for good. Or if
someone else wants to do it, I would recommend taking the dnotify backend and
just replacing any dnotify specific bits with inotify bits.

The real fix would be to factor out all of this extra logic out of the dnotify
backend and into a generic backend, that can make use of whatever OS-specific
backend (dnotify,inotify,kqueue) throug callbacks.

Please have a look at #172365. This bug here is most likely an artifact of the
gamin bug. In Ubuntu we had a similar report which was now reported as fixed by
our patched gamin version.

  

Created attachment 39700 [details] [review]
gamin-0.0.26-inotify-no-auto-deregister.patch

Tried above patch which looks to do similar to the one added to Ubuntu, but
alas, no go, so do not think its the same issue.  I *think* the problem is due
to /etc/fstab and /etc/mtab's watches not working for some reason (after adding
debug stuff to gnome-vfs).

The patch is just wrong. It will keep dnotify activated for any directory 
ever watched, you will end up exhausting the system limit of file descriptors
and force the kernel to generates flows of events to directory clients 
don't even have interest into. I won't apply that patch it is clearly
wrong.

Daniel

Created attachment 39740 [details] [review]
Fix inotify backend by always monitoring directory not just file

Problems with nautilus caused by monitoring of /etc/mtab
When media mounte/unmounted inode number of this file is changed,
so inotify doesnot send any event about /etc/mtab anymore.
As suggested by rlove in case gamin asked to monitor file, we
need to monitor directory with this file and then just filter event for our
file.

Created attachment 39790 [details] [review]
gamin_inotify_recursive2

Fix small meory leak in previous patch

Okay, I applied patch gamin_inotify_recursive2 (though it didn't apply 
cleanly as is, I think it conflicted slightly with another change, please
diff again CVs in the future).
It is untested on my side, maybe John will be able to check it at some point
but I may need to make a release soonish.

Daniel

Some of our guys have tested it with mixed results - two says it works fine,
another say it causes
a hardlock.  He will though check though with latest inotify patch in the next
day or so.

The patch isn't correct. It might work, but it is just bandaiding over a real bug.

Created attachment 39827 [details] [review]
Redo of inotify backend

I copied the dnotify backend, replaced all the dnotify bits with inotify bits.
Compiles, I haven't tested it.

Your patch is working itis good and itis so clean.
But what is the "real bug" ? I think itis doing basicaly the same
- never monitor specific file, but directory. Am i mistaken?

I can't even get gamin to run for me right now, so I haven't tested my patch. 

Yes, I am doing that, I always monitor a directory, and let the poll() backend
do all the work. But the way FAM was designed, it pretty much requires a poll()
backend, so I just dumbed down the inotify backend so that it works like the
dnotify backend, that is it just watches directories, and tells the poll backend
when something happens to one of them.

Created attachment 39840 [details] [review]
Rediff

I was not carefull when i tested your patch.
Now i checked again with nautilus.
It is working but CPU usage always 100%.
Will try to investigate.

Yeah, I finally got gamin to start for me, and I get the same problem. A strace
showed that gamin was stuck in a loop polling $HOME. Oddly, it never seemed to
read from inotify_device_fd, so  I don't think inotify is telling it to poll.

Thanks for looking into this.

Here is the final patch. The cpu problem was caused by inotify requesting a poll
every time a file was accessed, which then created more inotify events,
requesting more polls. Silly mistake on my part, but now inotify only asks for
polls after getting events that could have alterted files.

I have also tested inserting and removing media, and nautilus now seems to work
properly

Daniel, please apply this and if you have time make a release, this should
greatly improve the experience for inotify users.

Created attachment 45084 [details] [review]
Final patch

Seems to work all right here as well, thanks.

nice .it fixed also problem of using k3b from gnome.
With previous version after using k3b(or any another kde applciation) which
also use fam/gamin ,gamin did not sent properly events to gnome-vfs anymore.
Now itis working. I think itis should be committed instead of my dirty patch.

well, it seems that inotify 0.23 broke this again, and interaction with k3b too.
I'm not sure because I didn't apply the patch to 2.6.12 rc3 but to last 2.6.11
ck-sources, but everything seems to work with
inotify-0.22-rml-2.6.12-rc3-3.patch and not with inotify-0.23-rml-2.6.12-rc3-1.patch

Yes, We added SINGLE_SHOT mode, which removes a watch after the first event. Due
to a binary incompatible change, gamin is requesting single shot mode on every
watch. Fix is super trivial, and I will post a patch later today.

Status of inotify backend is now half-half.

Desktop refresh is not needed when copying and pasting stuff. But saving from
firefox to desktop will not show up and needs refresh.

Hotplugged devices appear in nautilus but are not checked again when they are
mounted by gnome-volume-manager. When you click on the apparently unmounted
icon, you will get error that it is already mounted and the icon will update and
show up on desktop.

I tried to look into the code but, seriously! didn't know where to start.

Can anyone else confirm Islam comments? For me, the inotify backend is working
fine. 

I can confirm his comments, with gamin cvs
however, I'm still using inotify 0.23 on a 2.6.11 kernel

Updated with CVS again and things improved a little. Now hotplugging the flash
stick works very well, gets mounted browsed , nautilus shows icon mounted,
desktop shows icon mounted , and when unmounting everything updates.

However saving from firefox to desktop still need a refresh for the download to
show up.

Also I have my partitions managed by HAL and gnome-volume-manager. at login all
partitions are mounted and this is shown in nautilus. I then procede to unmount
a  partition, the icon gets updated. Then I click on it, it gets mounted and
browsed. The problem is going to nautilus Computer:// again shows it still
unmounted! Same thing if I have another nautilus window showing Computer://
I have to press refresh, and then the icon updates to mounted.

I am using :

inotify-0.23-rml-2.6.12-rc3-4.patch

from kernel.org

no, sorry I take that back :( .. now something is messed up. The first
paragraph, hotplug will happen only once. Then it never picks up hotplug events
at all.

Maybe in this "hotplug" test case there are multiple issues? gnome-vfs, hal ,
dbus  or nautilus could be in the way. We should try to break down this into
pieces and work them out one by one.

I want to help but I don't know what to do. Please tell me :)

Yes I think I have traced the "happens one time only" hotplug behaviour to the
version of hal I am using.

The rest of the behaviour , IMHO , is not related to hal.

Giacomo, please upgrade and test again, I'm pretty sure that gamin CVS isn't
compatible with inotify 0.23.

Islam, can you please provide me with a gamin log? send the USR2 signal to
gam_server, and look in /tmp.

w.r.t. to comment #38, I'm sure I applied all your patches, so what is
missing ?

Daniel

Nothing is missing, inotify 0.23 is just too old for gamin cvs.

Just to clarify, you need to be using the LATEST (came out on monday) patch if
are you using CVS gamin. 

And, if you are having problems with the inotify backend missing events, please
provide me a log by sending USR2 to gam_server.

We're testing a gamin CVS snapshot which I produced, along with inotify 0.23-7.
Many people who have fed back to me report no problems, however I did experience
the "Desktop not updating" problem once yesterday. I've recompiled gamin with
debugging so I'll get some logs when it happens again.

http://www.reactivated.net/weblog/archives/2005/05/sorting-out-gamin-brokenness-testers-needed

Created attachment 46326 [details]
Quiet debug log

Ok, it broke after some stress testing. Here's 20 seconds of logging from /tmp,
where I wasn't doing anything with my Desktop

Created attachment 46328 [details]
Activity debug log

And here's a log where I created a file on my desktop and then removed it
(touch and rm in a gnome-terminal).. I don't think it shows anything of
interest though :(

Slightly different test, I enabled logging, and started a tail -f on that file.
In another terminal, I then touched a new file on my desktop. The immediate
response was this appearing in the logs:

inotify recieved 1 events
inotify recieved 1 events
inotify can't find wd 3
inotify recieved 1 events
inotify can't find wd 3
inotify recieved 1 events
inotify can't find wd 3
inotify recieved 1 events
inotify can't find wd 3
inotify recieved 1 events

This is enough to kill it for me:

while true; do touch ~/Desktop/testfile; sleep 0.5; rm ~/Desktop/testfile; sleep
0.5; done

It seems to help being under some load (compiling stuff). Then as soon as I open
a big app (such as mozilla), and minimize it, the desktop has stopped
automatically updating.

sorry I am late, I had an exam.
I updated my kernel with latest patch for rc3 from kernel.org

I updated to gamin-cvs ( I am going to try the new 0.1.0 release shortly )

In the process I updated HAL and dbus to the experimental release so the mount
and  icon things are not working until I figure them out. Anyway that test case
was wrong.

I did a similar test to Daniel's one, it was suggested on gentopia's website:

for i in `seq 1 20`; do echo $i; echo “aaaaaaaaaaa” > ~/Desktop/aaa.txt; sleep
2; rm ~/Desktop/aaa.txt; sleep 2; done

This worked ok.

But if I reduced the delay to 0.5

for i in `seq 1 20`; do echo $i; echo “aaaaaaaaaaa” > ~/Desktop/aaa.txt; sleep
0.5; rm ~/Desktop/aaa.txt; sleep 0.5; done

it stopped updating in sync around iteration 7 or 8. Then it picked up at
iteration 12 , then stopped updating , then in the end picked up the final delete.

adding another variable to the test, having firefox saving a download to the
desktop ( which creates two files one of which is constatly being modified )
made it stop  working earlier , iteration 1 or 2 , and then it picks up the last
delete.

The good thing now is that in the end it will always show the correct state of
the desktop. 

Ps. is there a refresh frequency of the desktop set in nautilus? because if
there is then it's useless to go above that frequency.

I upgraded yesterday to gamin 0.1.0 with inotify 0.23-7. Mounting/unmounting
removable devices and filesystems now works good, but I can still notice just
two glitches:

* stress-testing gamin with script that create and remove object from desktop
ends with the desktop not being updated anymore
* after a normal 4-5 hours session *without* stress-testing, icons for new files
on Desktop didn't appear

curiously, in the second case icons for mounted/unmounted filesystems continued
to work without problems.

I think that the Desktop problem is more general. I just noticed that if I leave
a nautilus window open for a while (more than 10 minutes but less than 1 hour)
gamin doesn't monitor that window anymore.

Hey everybody, sorry for the long delay in getting around to fixing this.

Well I have some good news and some bad news. The good news is, that I found a
bug in the gamin inotify backend code that could have been causing this bug.

The bad news is that the bug still isn't fixed, but I have more information.

So what happens is the poll backend asks inotify to stop monitoring the ~/Desktop. 

The poll backend does this to control the amount of poll's() requested on a
particular path.

The bug we are all suffering is caused by the poll backend never telling inotify
to re-activate the backend for ~/Desktop.

Daniel V, what exactly triggers flow control START/STOP events? Do you have any
idea why the poll backend would NOT be stopping flow control?

I have attached a new patch that fixes a real bug in the inotify backend. Please
apply.

Created attachment 46808 [details] [review]
IN_IGNORE bug fix.

Created attachment 46809 [details] [review]
Disable flow control experimental patch

I have just posted a new patch, that simply #if 0's the flow control code out. 

AFAICT this fixes the bug.

Daniel V, I am using the exact same code as the dnotify backend for flow
control, have I mucked something up or is this a real bug in the poll backend?

The poll back-end reactivate kernel monitoring after 10 second without
any activity on the given resource. (gam_poll_flowoff_node() called at
the end of poll_file())


Daniel

Okay, then my IN_IGNORE bug fix patch will probably fix the bug then. I was just
impatient and definitely didn't wait 10 seconds before stopping the test. 

Can anyone confirm if the IN_IGNORE bug fix patch fixes there problems?
(Remember to wait 10 seconds to see if things update again).

Daniel V, could you apply the IN_IGNORE bug fix patch? 

Can anyone post test results?

I would rather have John post it to the list so I'm sure it's the final
version. 

Daniel

I've tested both the patches: the "disable flow control" patch fixes my problems
(comment #49), the "IN_IGNORE" doesn't fix them.

With the IN_IGNORE patch, did you wait for a full 10 seconds to see if the watch
is re-activated? When a watch is marked busy, no activity will be reported on it
for 10 seconds. The only difference between the patches is the 'disable flow
control' patch ignores the busy-deactivate request from further up in gamin.

DV, do you think 10 seconds is maybe too long of a delay? What about dropping it
to 2?

I'm not sure I can comment if this is adequate or not. For dnotify what happen
is the following:
   - if a resource generated more than 4 kernel events in less than
     a second it's marked busy, the kernel monitoring is stopped
   - from that point that resource is watched using polling i.e. 
     checked once per second
   - once the pollig mode didn't detect any change for 10 seconds,
     the resource is removed from the busy list and kernel monitoring
     for it is reactivated.

 10 second without any monitoring at all sounds a bit long.

Daniel

Okay, I misunderstood, I thought that once a resource was considered busy, the
poll backend stopped checking for 10 seconds. 

I don't see why the inotify backend is having problems. All that inotify does on
events is let the poll backend know that something happened to directory X. 

The poll backend decides when to tell inotify to start/stop watching a directory
using the kernel. 

What is happening is the poll backend is telling inotify to stop monitoring
directory Y, and then everything stops.

I have been doing some more gamin debugging, and I have noticed that inotify
isn't even asked to watch /etc/fstab or /etc/mtab. 

isub wd 1 refs 1 busy 0 deactivated 0: /home/ttb/.gnome2/nautilus-scripts
isub wd 2 refs 1 busy 0 deactivated 0: /home/ttb/Templates
isub wd 3 refs 2 busy 0 deactivated 0: /home/ttb/Desktop
isub wd 4 refs 1 busy 0 deactivated 0: /home/ttb/.tomboy/Plugins
isub wd 5 refs 2 busy 0 deactivated 0: /home/ttb
isub wd 6 refs 2 busy 0 deactivated 0: /home/ttb/Desktop/torrent
isub wd 0 refs 1 busy 0 deactivated 0: /home/ttb/.Trash

That is the list of inotify subscriptions. Daniel, Is this normal? Does the
dnotify backend watch /etc or is the poll code entirely responsible for /etc ?

I can't answer that question. Gamin won't watch /etc by itself. It will
watch it only if some application asks for it. And that is completely
dependant on your environment, i.e. what programs are running.
Or maybe I misunderstood your question.

Daniel

I was asking if gamin would use the kernel backends to watch /etc or would the
poll backend be special cased for /etc ? I have now found my bug and now inotify
watches /etc like dnotify does.

I am attaching a patch that contains a few things. 

1) Updates inotify backend to be work like the dnotify backend.
2) Updates the poll backend to treat the inotify backend the same as dnotify.
3) Adds kernel subscription debug output for inotify and dnotify backends.

Please go ahead and commit this.

Here is the kernel subscription output for inotify & dnotify running gnome 2.10,

They are identical now, except for order.

dsub fd 7 refs 4 busy 0 deactivated 0: /home/ttb/.local/share/applications
dsub fd 14 refs 1 busy 0 deactivated 0: /home/ttb/.gnome2/nautilus-scripts
dsub fd 9 refs 3 busy 0 deactivated 0: /home/ttb
dsub fd 18 refs 1 busy 0 deactivated 0: /home/ttb/.tomboy/Plugins
dsub fd 15 refs 1 busy 0 deactivated 0: /home/ttb/Templates
dsub fd 16 refs 3 busy 0 deactivated 0: /home/ttb/Desktop
dsub fd 11 refs 2 busy 0 deactivated 0: /etc
dsub fd 13 refs 1 busy 0 deactivated 0: /home/ttb/.Trash
dsub fd 5 refs 6 busy 0 deactivated 0: /usr/local/share/applications
dsub fd 4 refs 6 busy 0 deactivated 0: /usr/share/applications
dsub fd 6 refs 6 busy 0 deactivated 0: /usr/share/gnome/applications

isub wd 3 refs 4 busy 0 deactivated 0: /home/ttb/.local/share/applications
isub wd 7 refs 1 busy 0 deactivated 0: /home/ttb/.gnome2/nautilus-scripts
isub wd 5 refs 3 busy 0 deactivated 0: /home/ttb
isub wd 8 refs 1 busy 0 deactivated 0: /home/ttb/Templates
isub wd 9 refs 3 busy 0 deactivated 0: /home/ttb/Desktop
isub wd 10 refs 1 busy 0 deactivated 0: /home/ttb/.tomboy/Plugins
isub wd 4 refs 2 busy 0 deactivated 0: /etc
isub wd 6 refs 1 busy 0 deactivated 0: /home/ttb/.Trash
isub wd 1 refs 4 busy 0 deactivated 0: /usr/local/share/applications
isub wd 0 refs 4 busy 0 deactivated 0: /usr/share/applications
isub wd 2 refs 4 busy 0 deactivated 0: /usr/share/gnome/applications

Created attachment 47660 [details] [review]
Latest Patch

Compile fails with patch applied:

make[3]: Entering directory `/u/veillard/gamin/server'
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I../libgamin -I../protocol -I../lib -
I../libgamin -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DBINDIR=\""/
usr/libexec"\" -DG_DISABLE_DEPRECATED -DGAM_DEBUG_ENABLED    -Wno-sign-compare -
Wall    -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes   -Wnested
-externs        -Wsign-compare  -g -O2 -MT gam_inotify.o -MD -MP -MF ".deps/gam_
inotify.Tpo" -c -o gam_inotify.o gam_inotify.c; \
then mv -f ".deps/gam_inotify.Tpo" ".deps/gam_inotify.Po"; else rm -f ".deps/gam
_inotify.Tpo"; exit 1; fi
gam_inotify.c:71: warning: no previous prototype for 'gam_inotify_data_debug'
gam_inotify.c: In function `gam_inotify_directory_handler_internal':
gam_inotify.c:268: error: `dir' undeclared (first use in this function)
gam_inotify.c:268: error: (Each undeclared identifier is reported only once
gam_inotify.c:268: error: for each function it appears in.)
make[3]: *** [gam_inotify.o] Error 1
make[3]: Leaving directory `/u/veillard/gamin/server'

Daniel

Yep, I wasn't compiling with GAMIN_DEBUG_API defined. Attaching fixed patch.

Created attachment 47689 [details] [review]
fixed patch

I had to change gam_poll_init_full() otherwise gam_server would
not even start on a dnotify system with your patch, but once done
I don't see any more breakage, so this is applied and commited :-)

  thanks,

Daniel

I upgrade yesterday to current CVS (20050616) and I noticed a lot of regression
in comparison to 0.1.0 + Disable-flow-control-experimental patch:

* randomly (I haven't found a pattern, it can happens after 20 minutes or 2
hours) gam_server starts using 100% CPU, and the only fix is closing and
restarting gnome
* if I leave a nautilus window open, after a while (~1 hour) new files don't
show anymore
* the same happens for desktop
* after a longer (~3 hours) time icons for mounted devices don't show on desktop
and restarting gam_server/nautilus/g-v-m doesn't fix this

I've got an exam on monday, after that day I'll try to provide some debug info

I can't reproduce the 100% CPU usage problem. But I am having a problem with
watches going dead after a bit of time. From my debugging, gam_server is dumping
core, but I can't reproduce exactly what is causing it. I just get a ~/core from
time to time. 

Daniel, I can't seem to debug gam_server in gdb. For example, if I run this:
"gdb /usr/bin/gam_server `pidof gam_server`", I get this:

Attaching to program: /usr/bin/gam_server, process 11800
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
0x4017c4d9 in ?? ()
(gdb) bt

+ Trace 61214

Which is just junk.

Also, if I start gam_server using valgrind OR gdb with the "--notimeout" option,
the gam_server behaves as if it is dead.

I can't find this bug without being able to catch the crash. Any hints?

Okay, I have managed to catch the crash. Backtrace below. It seems, the BEEP
Media Player is cancelling a subscription with a path = "". 

(gdb) print *req
$6 = {len = 10, version = 1, seq = 2, type = 3, pathlen = 0,
  path = '\0' <repeats 4061 times>, "\uffffo\n\b\000\000\000\0009", '\0'
<repeats 11 times>, "\uffff\uffff\n@\001\000\000\000`,\a\b\uffff\000"}

This causes gam_remove_subscription to be called with a NULL subscription, which
bubbles up until gam_node_remove_subscription makes the assertion: 

g_assert(g_list_find(node->subs, sub));

Which causes the server to abort.

Actually on further study, in the function gam_connection_request the
subscription isn't NULL.

+ Trace 61220

Well, playing around with BEEP Media Player, I can definitely reproduce this crash. 

Steps:

1) Start beep
2) Clear playlist
3) Add tracks to play list

gam_server crashes.

This crash is actually caused by the gtk file selector. 

Can anyone reproduce this bug? Or has debian screwed something up. Every time
the gtk+ file selector is opened, gam_server crashes for me.

We are hitting an assert. That mean there is an abnormal condition being
detected in the server. If you can make a global description of it,
and post about it in a new bug and/or the list that would be useful.
Hammering on that older bug for something completely different makes no
sense to me. And bugzilla is not my preferred communication channel,
the list is, bugzilla is for informations about bugs. I think from
the stack in #73 it should be relatively easy to get the fix. Run gam server
in debug mode and watch the assert which was raised.

Daniel

I can't reproduce this. At least, checking the pid of gam_server with ps, then
opening the "add file" dialog in beep, then checking the pid again, shows that
the pid hasn't changed.

sorry, for hijacking again this bug, but referring to comment #71 I have to tell
that I've been using in the last few days gamin 0.1.1 from gentoo (it includes
this patch:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-admin/gamin/files/gamin-0.1.1-inotify-fix.patch?rev=1.1&content-type=text/plain
) and I never experienced 100% CPU usage or nautilus ceasing to monitor
directories, so my problems could be due to changes in CVS after that release.