I created a course for a colleague to use as a sandbox in the fall. It was subsequently renamed to be used as a real course this spring. Some problems which were fine in November malfunctioned recently for my colleague while continuing to work for her students.
I found lots of broken symbolic links in the course's html/tmp/gif subdirectory. It turns out they used an absolute path involving the original name for the course. After cd'ing to the current course's subdirectory, the command
sudo find -L . -type l -delete
removed them. (Caution: replace "-delete" with "-print" for your first experiment with that command.) Since some problems used the LiveGraphics3D applet, that command needed to be repeated in html/tmp/html (or could have been invoked 2 levels up).
Would it be a fix to have the WeBWorK procedure(s) creating those symbolic link use relative paths?
Changing the name of the course would leave lots of links in the html/tmp/gif directory pointing to non-existent files (they point to within the old, now non-existent, directory containing the old course).
On the one hand it's good to periodically clean out these tmp directories as you describe.
On the other hand I don't see why this would cause a problem with the new course -- the new course should simply create new links in the html/tmp/gif directory which point to the new correct location for the resource. (The old links hang around but do no harm except for taking up space.) This is also one of the reasons you can safely clean out anything in the html/tmp directory -- it should be created automatically. I believe that even the toplevel tmp/gif, tmp/html and tmp/hardcopy directories will be created automatically, although ensuring that their permissions are set correctly has been a trial.
Cleaning out the tmp directory too often will slow things down because the links (and sometimes the graphs themselves) will have to be created anew every time.
I'm puzzled about why any questions created by the new course would point to the old links since the address is created out of a combination of course name, user name and problem set version number. Can you give a specific example of a question and how this went wrong?
In the newest versions of PGalias.pm we are moving to replacing the path descriptors with UID (unique identifiers) created from course name user name and psvn version numbers in order to increase privacy and security. In the current system, if one is diligent enough, one can discover various facts about the user and questions in the course by inspecting the paths to the graphs -- in the new system the paths to the links will be apparently meaningless codes. Unless you have system access you will not be able to determine where the links point to.
The broken symbolic links were created for assignments to instructor (and 2 or 3 test "users") during the sandbox phase. Those assignments were subsequently assigned to students after the course had been renamed --- there have been no difficulties involving those student assignments.
My main reason for using find to locate+zap broken sym-links was to retain all of the working links in order to avoid slowing student access to problems they had seen before. (This is related to old-timey use of image_precreate ;-)
I usually keep a sandbox course as a hidden shadow of a working course. This was my first occasion to convert a sandbox into a working course (and I hope there are no more gotcha's).
My main reason for using find to locate+zap broken sym-links was to retain all of the working links in order to avoid slowing student access to problems they had seen before. (This is related to old-timey use of image_precreate ;-)
I usually keep a sandbox course as a hidden shadow of a working course. This was my first occasion to convert a sandbox into a working course (and I hope there are no more gotcha's).
OK. I can duplicate it now. So far it only happens with static pictures (places where there is a link back to the file in the template directory) -- there doesn't seem to be a problem with on the fly graphics. The path name to the link doesn't include the name of the course after all so when the course name is changed the alias address still goes to the old address. I'll make sure that the new addressing mechanism is sensitive to the name of the course as well as the user data. That should prevent this particular problem.