Menu
▾
▴
#110 Temp file issue
Scrollkeeper merges content lists of various locales
when offering a final content list to the help browser.
Usually the current locale and C are merged. The
purpose of this is to offer English versions of
untranslated documents to the user. The final content
list will be in a temporary file in /tmp. The file is
created in cl/src/get-cl.c. According to the algorithm
5 temp files are used, if there is any not created yet,
that will be used for the next merged content list, if
all of them exist then the oldest one will be used.
This algorithm fails if more than one users use the
machine as they are not able to overwrite each others
temp files.
Logged In: YES
user_id=72575
The algorithm also fails if a user switches between their
own account and root and uses the help in between. This is a
very common task when configuring things on the machine.
Logged In: YES
user_id=72575
The algorithm also fails if a user switches between their
own account and root and uses the help in between. This is a
very common task when configuring things on the machine.
Logged In: YES
user_id=65682
This was also related to a security problem a while back. It
should be fixed in CVS (if not, I've screwed up again).
Long term, we need to redo this -- if you can tolerate
ploughing through the Sourceforge mailing list archives,
there was a thread about it a couple of months back -- but
for the very short-term, we are OK (modulo having a bunch of
files scattered in /tmp).
I won't close this bug yet, since you have put the doubt in
my mind that I may have botched it. But I think this is a "dup".
Logged In: YES
user_id=65682
Whoops. :-( I am an idiot (no great surprise).
We never got around to fixing this problem at all. So it's
definitely an open bug. I am trying to clear out my patch
queue this evening (i.e. right now), so I'll see if I can
get something working here, too.
Logged In: YES
user_id=72575
I suppose the obvious way is to try to incorporate the user
name into the temp file name. An engineer here was saying
that we should dump it to stdout when scrollkeeper-get-cl is
called rather than into a temp file. That of course would be
an API interface change that will cause problems for help
browsers using Scrollkeeper.
Logged In: YES
user_id=65682
I was thinking about swiping some code from ORBit2, which
makes a per-user subdirectory for storing a bunch of files
that it needs. It creates the directories safely, etc, so
that might save some brainpower if it can be copied easily
(there are no license problems; it's just a matter of how
orthogonal to the rest of the code that fragment is).
Essentially we are thinking the same way though.
I agree that ideally we want to dump the results to stdout,
however there is a noticable performance impact (Mikael
Hallendal and I experimented with this a couple of years ago
when he was first writing Yelp). The merging of the
localised contents seems to be the blockage, so Yelp, at
least, was much more responsive when it could just read the
same file over and over again. Of course, there are problems
there, too (like the user deleting the file). I can't
remember why Yelp doesn't just keep stuff in memory, which
should not be too onerous.
Medium term (version 0.5.x?) we need to work this out
properly so that applications which want to can use some of
the scrollkeeper stuff more like a library and avoid all
this file writing. All the fork/exec stuff a client
application needs to do is really not ideal in our current
model.
Logged In: YES
user_id=72575
Just found out that the Solaris Gnome maintainers fixed this
by putting the temp files into /tmp/scrollkeeper-<username>
like folders. If you are ok with this fix I can get you a
patch that applies to 0.3.12 or HEAD in a couple of days.
Logged In: YES
user_id=65682
That's the same way I was going to do it (inspired by
ORBit2), so I have no problem with the design.
I am very happy with you extracting a patch from your end,
since then I will have confidence that
(a) it builds on non-GNU systems, and
(b) some serious people have looked at it and tested it.
Just extract the patch in whichever way is easier for you
(i.e. if it doesn't automatically work against HEAD, I can
sandpaper the corners until it fits).
Much obliged. :-)
Logged In: YES
user_id=65682
This problem should be fixed in the 0.3.13 release (released on 7
Dec 2003). Thankyou for taking the time to make a bug report.
- Malcolm