[Bug 64081] Shows warning "file modified on disc" whenever I save a file

[Tim Smith]

(Thread all busted because I was following this via lists.kde.org 
originally)

Roberto Raggi <roberto at kdevelop.org> wrote:
> Hi,
> Thanks a lot for your very detailed informations ;)
> maybe this bug can be fixed in kate part. From what I've understand, kate 
> doesn't check the ctime if the file is *dirty*! maybe, if kate will check 
the 
> ctime before emit the IamChanged() signal the problem will be solved.

Yes, kate could check the ctime right after it saves the file, store that 
value and then check the ctime again after it receives a change 
notification from KDirWatch, to see if it really has changed, and that 
would fix the problem in kate, but not in general. In general, every 
application that can be a part would have to do that, just in case the app 
it was a part of was watching the same file.

I'm more inclined to see this as a bug in KDirWatch, in that when I register 
a request to recieve change notifications, I do *not* want to recieve 
notifications for changes that ocurred before I registered interest. 
KDirWatch is delivering a late notification because it is relying on an 
asynchronous source (FAM) but that's not *my* problem.

It seems better to fix it in KDirWatch, because that fixes it everywhere. 
I'm willing to do that, unless someone on kde-devel (CC'd) really objects 
to having it solved there.

> 
> On Monday 15 September 2003 18:11, tim at electronghost.co.uk wrote:
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> >
> > http://bugs.kde.org/show_bug.cgi?id=64081
> >
> >
> >
> >
> > ------- Additional Comments From tim at electronghost.co.uk  2003-09-15 
18:11
> > ------- Kate removes the file from the watch list before saving and adds 
it
> > again afterwards. This is its strategy for trying not to get change
> > notifications for changes it caused itself. In standalone kate, it 
works.
> >
> > However, there is somebody else watching it at that point
> > (kdevelop/src/partcontroller.cpp line 437) so kdirwatch never actually
> > removes it from the watch list.
> >
> > This means it doesn't get statted on re-adding because it's already 
there,
> > and there's now a race. Kate removes-writes-adds before FAM gets around 
to
> > checking, and lo and behold, when it does check, the file has changed.
> >
> > Observe some debug output from gideon immediately following a save:
> >
> > kio (KDirWatch): Added already watched Entry /home/tim/cvs/taskmaster/
src/
> > taskmastermainwidget.h (now 2 clients) [KDirWatch-3]
> >
> > kdevelop (core): MainWindowIDEAl::slotPartJobCompleted()
> > gideon: BookmarksPart::reload()
> >
> > kdevelop (core): dcop emitting savedFile /home/tim/cvs/taskmaster/src/
> > taskmastermainwidget.h
> >
> > kio (KDirWatch): Processing FAM event (FAMChanged,
> > /home/tim/cvs/taskmaster/src/ taskmastermainwidget.h, Req 3)
> >
> > kio (KDirWatch): KDirWatch-1 emitting dirty /home/tim/cvs/taskmaster/
src/
> > taskmastermainwidget.h
> >
> > kio (KDirWatch): KDirWatch-3 emitting dirty /home/tim/cvs/taskmaster/
src/
> > taskmastermainwidget.h
> >
> >
> > Note how the FAM event comes in *after* the "adding already watched 
entry".
> >
> > KDirWatch could fix this problem by forcing a recheck of a file's status
> > whenever something adds an already monitored file, just before adding 
the
> > requestor to the list of interested parties.
> >

-- 
Tim Smith (tim at electronghost.co.uk)
"Reactions to his invention were immediate and far-reaching: the normally
phlegmatic British were aroused into a state of frenzied apathy...."