Ok Graff... here goes nothing.
Lets say you get into a accident and your insurance adjuster comes out to take pictures of your car (Progressive, State Farm, we deal with all the large ones). The adjuster uses our software to upload the pictures into our systems. When they are uploaded they go into this gigantic file system that no one will let me archive.
When uploaded a simultaneous entry goes into a database table. Some customers use an application that looks to the database which points back to this large file system. Other companies do not use the software which requires the db or the files in the FS, so the large jpegs sit there doing nothing. Luckily some customers have given us the go ahead to zero out the jpegs. The name will still exist so the db wont puke, but they don't eat up all the space.
Probably more than you wanted to know about a poorly designed work flow that has been in place since I was a toddler. | [reply] |
So if the idea is to keep existing functionality "functional", you might consider: rather than having a bunch of zero-length jpeg files (which might create a bad "edge condition" for some applications), you could unlink the existing file and replace it with a symbolic link (same file name) pointing to some known and suitable image (in an ms-windows file system, the term would presumably be "short cut", but it's the thing created by the perl "symlink" function).
IOW, instead of having a (few) million distinct jpeg files that you don't need, you have that many symlinks to a single image file. You could even have some fun with that... you know, kittens and/or puppies and/or infants, or maybe a mushroom cloud or one of those "sculptures" consisting of part of a car sticking out of the ground... Something that could give the viewers a chuckle in the context of reviewing a car insurance claim. (Oh wait, do insurance agents have a sense of humor?)
| [reply] |
I'd like to link them all to a picture of me not sleeping at night!
| [reply] |