Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#19 pictures gone



First off all I like Slooze alot. one thing I would like to
point out and if someone can help me to solve it that
would be great.

It seems that after a lot of views my pictures are gone.
I mean that after a period of 300 views my pictures are
gone. The links to the pictures are there but the
pictures doesent show.

does anyone know about this problem and is there a
solution ???


Remco S


  • Logged In: NO

    I have that problem too. I'm using the text-based version.

  • Logged In: NO

    i have had this same problem on a high-traffic site.... still can't figure out how to fix it. i am using flat files as the back end

  • Logged In: YES

    This is a concurency problem and stems from the use of text
    file storage combined with enabling features which can write
    back to the files.
    The problem happens on a high traffic site when two requests
    happen almost simultaneously. Say you have page view
    counting turned on. One user views a page which causes
    slooze to read the pictures file, increment the page count for
    the viewed picture, then write the file back out to the disc. If
    another user views a picture page right at this moment, the
    instance of Slooze that is serving him may read the pictures
    file whilst it is only half-written. After rendering the page it will
    increment the views count and write its (incomplete) data
    back to the pictures file. It doesn't matter that by this time the
    first instance has finished writting the whole file - it gets
    overwritten by the incomplete version and you are hosed.
    The Slooze website says "Views counting is not
    recommended for sites with heavy traffic." which is
    reasonably good advice when using text files.
    Databases are designed to solve just such concurency
    problems and you should not see this issue if you are using
    database storage.
    Slooze does currently try and get an exclusive lock on the file
    when writing to it but it seems this is not sufficient to prevent
    the problem in all situations. I will try and add some more
    checking to improve matters, but your best bet for absolute
    stability is to use a database like MySQL or, if you are going
    to use text file storage to disable views counting and make a
    backup of the pictures.txt file so you can easily restore things
    if a problem ever arises (which is good advice anyway).

    • status: open --> closed
  • Logged In: YES

    Added write of end-of-file marker to Csv::write and
    corresponding check to ensure that file is completely read to

    • status: closed --> closed-fixed