Creating & Destroying Collision-proof File Cache Locations
by Mike Levin SEO & Datamaster, 06/05/2012
Okay, we cut the journal entry. Fully motivated. Get down to business. We have two functions in place: one to be a sample function that needs to save stuff, and the other to be the equivalent of the “lock” to use at its beginning. That has been the hardest part to get started with. I actually got rid of the need for the calling function to pass anything about its own name, because that is available through Python as:
…but who would have known it? As awesome as I think Python is, there are these mysterious internals that could be named better. The scavenger-hunt that I hate so much about other languages class-libraries does exist in Python too. It’s just you don’t need to go to them as often, and the dot-this-dot-that paths aren’t as infuriating. But this is quite infuriating. Python would be nothing without Google, and that’s a problem.
Okay, so we have the calling function name always being returned, but without passing around a ton of parameters, I need to grab the…
Okay, I got very distracted by a request that came in. I also took in a little bit of the start-up company demos that are going on today. But again, I am discouraged by how little actual work I’m getting done. Am I really just that distractible, or is it my environment, or what? Okay, bear down and get shit done…
Okay, make the function that creates the folder-name create the correct name my making a compound string out of their email address and the function name, replacing the at-sign with… let’s say, double-underscores. Okay, now we’re getting somewhere. Now, make it check for a directory of that name inside of /tmp/. Okay, I have the directory checked-for and conditionally created. Oops, further naming collisions are required based on the bookmarklet they’re using, because each webhead can host multiple bookmarklets. Okay, done.
Hmmmmm. Now, we should symmetrically destroy those directories when Tiger exits, regardless. Hmmmm. Also, there should be an unconditional cleaning out of the whole cache space when Tiger starts. I don’t want doubling-up of the files that get sent each time. This thing should be programmed fail-safe.
Okay, so there’s an initialization step that cleans out the entire location. So the location can’t just be a bunch of collision-proofed named directories. It has to be a single directory containing them. So identify the location in Tiger where this initialization should occur. Oops… not that simple! Each bookmark and each user needs their own directory. So, this initialization stage just has to ensure /tmp/[cfg.HOSTNAME] exits. That never gets deleted. But INSIDE of that, the folder for the individual user DOES get deleted on initialization.
Okay, it was a bit tricky to work out, but there is the consistent attempt to create a file cache location for the bookmarklet in /tmp/ which never gets destroyed. But then, there’s always the attempt to delete a folder by that username inside… well, you get it. It’s time to leave today, but I definitely have the directory creation and destroying necessary to guarantee a place to process files WHILE Tiger is running for any function that needs it, but then which cleans up after itself to avoid file cruft.
This was not the ENTIRE project I wanted to get done today, but it certainly di go a long way. A huge hurdle is out of the way for Tiger’s ability to create and send along large files, which will not only be useful for Tameka’s project, but will let me say “yes” to a whole class of requests that I’ve been shying away from to date.