#110 Temp file issue

bug
closed-fixed
2
2003-12-05
2003-09-01
No

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.

Discussion

  • Laszlo Kovacs

    Laszlo Kovacs - 2003-09-01

    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.

     
  • Laszlo Kovacs

    Laszlo Kovacs - 2003-09-01

    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.

     
  • Malcolm Tredinnick

    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".

     
  • Malcolm Tredinnick

    • assigned_to: nobody --> malcolmt
    • status: open --> open-accepted
     
  • Malcolm Tredinnick

    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.

     
  • Laszlo Kovacs

    Laszlo Kovacs - 2003-09-02

    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.

     
  • Malcolm Tredinnick

    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.

     
  • Laszlo Kovacs

    Laszlo Kovacs - 2003-09-03

    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.

     
  • Malcolm Tredinnick

    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. :-)

     
  • Malcolm Tredinnick

    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

     
  • Malcolm Tredinnick

    • status: open-accepted --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks