By design intent, files stored in ~/Library/Caches
should always be safe to delete, at least as long as the application isn't running. You can mitigate any poor programming bugs by moving them to trash and then rebooting the mac before you empty the trash as this ensures whatever programs are running can still write files to that old cache directory but will be forced to make a new Cache folder the next time it starts.
In your specific instance, the folder/files in question are created by iPhoto when you start a slide show. It seems that they do not get removed when you exit iPhoto later on so you have to remove them manually if you want to recover the disk space.
You could use dtrace to determine what is creating the file, say using iosnoop.d which runs under dtrace will reveal which applications are using the disk and what files they are reading or writing. This would imply catching its creation or write access, "live".
If that doesn't reveal who's created the file it could be because the process is communicating more tightly with the filessytem and hfsslower.d may be required to locating the IO to this file.
You could also see if the file is open currently, and if so by whom, using lsof
.
The above suggestions should reveal what's writing this file, which I believe is the root of your question.
But to specifically answer your question, no you should not "lock" the root directory of your startup disk as this is not an advisable safe practice and may prevent the OS from booting or functioning as expected. I presume here that by locking you mean the Finder concept of locking a file, or the POSIX concepts of restricting permissions and using the uchg/schg file flags via chflags. While Mac OS X doesn't normally create new files in this location arbitrarily, changes in permissions and ownership could effect filesystem traversal by users and processes and in general *nix systems expect the root volume directory to be mutable. Many processes and commands in *nix use this as a fallback default, and it's often seen used in certain cases where a login occurs and there's no HOME, for instance. While it may ave no immediate short term negative effects, it's not a wise practice nor is it the best method to determine what's causing your mysterious file creation.
Knowing more about the file might also help answer your underlying question.
Best Answer
WiFiDiagnostics*
sounds like something you can delete without impact. There are other things in/private/var/tmp
which probably shouldn't get deleted (e.g.filesystemui.socket
) sorm *
is not advisable.