Scratch

We have the same issue in our school. Kids come to the lab, log in to a shared network account, and end up losing their work when their saves interfere. Please advise...thank you,

-- MB

I wrote a patch that incorporates fetta's advice to use a random naming scheme for tmp files. The change is in the method System-Files,FileDirectory>>unusedNameStartingWith: (from the Scratch 1.4 source code).

Original code:

unusedNameStartingWith: prefix
    "Answer an unused file or directory name in this directory starting with the given prefix and ending with one or more digits."
    "FileDirectory default unusedNameStartingWith: 'tmp'"

    | usedNames i result |
    usedNames _ self fileAndDirectoryNames asSet.
    i _ 0.
    result _ prefix, '0'.
    [usedNames includes: result] whileTrue: [
        result _ prefix, (i _ i + 1) printString].
    ^ pathName, self slash, result

Modified code:

unusedNameStartingWith: prefix
    "Answer an unused file or directory name in this directory starting with the given prefix and ending with one to six random digits."
    "FileDirectory default unusedNameStartingWith: 'tmp'"

    | usedNames result |
    usedNames _ self fileAndDirectoryNames asSet.
    [usedNames includes: (result _ prefix, (1000000 atRandom - 1) printString)] whileTrue: [].
    ^ pathName, self slash, result

The first (unmodified) version will try tmp0, then tmp1 if that fails, etc. The second version will try tmp299266, tmp668132, etc. where the suffix is a random from 1 to 999999.

Regarding what fg123 said, on my computer Scratch does not make any temporary files except for tmp0, tmp1, etc. when saving.

Kudos to Fetta for figuring out this problem.

When Scratch saves a project, it writes it to a temporary file to avoid writing over the previous version, which could leave a broken project if the write failed partway through. After the project has been completely written to the temporary file, Scratch deletes the old project file and renames the temporary file. When choosing a temporary file name, it tries to avoid using a temporary file name that already exists. However, in a distributed system, this creates a race condition: two instances of Scratch might both read the directory and choose the same unused temporary file name at the same time. If Windows handles caches remote directories, this problem is more likely (larger time window, so greater chance of two writers choosing the same temporary name).

The fix posted by captainobvious is excellent. It doesn't remove the inherent race condition, but it reduces the probability of name conflicts dramatically. Thanks!

I've added this bug and the fix to our bug database, and we'll include it in Scratch 1.4.1. However, since we are working on a new version of Scratch in Flash, it's not clear when (or even if) we'll do a Scratch 1.4.1 release.

Meanwhile, one way to work around this issue would be to create a folder for each user, and have them save their work there. I realize this is not ideal, but it's better than the risk of losing projects. Fetta's idea of saving locally, then copying the project to the shared drive would also work, although I see how this could be difficult for young users to remember.

  -- John