Disk blocks aren't timestamped, and the FBI is even looking at disk free space, so there may not even be a directory entry that can show when the image was placed there.
Besides, a "smart" Geeksquad employee could just backdate the comptuer's clock or manipulate the file creation time directly to make it look like the image was placed there when the owner had the computer in his posession.
Timestomping, the name for what you are describing, is easy to do and easy to detect.
There are lots of advanced techniques to manipulate various aspects of Time related artifacts, but there are also lots of advanced techniques for determining whether a system has been tampered with. A skilled person might be able to erase evidence of exactly what they did, but often this creates artifacts or even an absence of artifacts that can be used to determine that someone tampered with the system in an attempt to cover his tracks.
I specialize in forensics in the context of incident response, so I don't typically run into anti-forensic techniques as sophisticated as law enforcement analysts may encounter. Perhaps there are ways to completely avoid detection. However, I imagine it would be difficult.
If we assume they can't break full-disk encryption (which is not unlikely), are you certain?
A proper encryption protocol consists of not only the encryption itself, but also authentication, verification and integrity checks. These are for protection against things like replay-attacks and indeed, tampering.
IIRC, booting a laptop with an encrypted FS, normally you'd enter your password, it'd apply a key-generating function (to turn the password into a proper 256bit AES key, or whatever's required), discard the password from memory and then use the key for operating a symmetric cipher (like AES) on the FS's read/write operations.
However, that doesn't quite work, it's not enough to do just that. An encrypted FS also needs authentication and verification, otherwise you open up yourself against all sorts of sneaky attacks stripping your encryption. So AFAIK, the system also keeps checksums and signatures with HMACs or something.
Admittedly, I don't know the exact details. One thing I'm not sure about is if there's the option of having some public/private key available for a bit of assymmetric encryption. Performance-wise you can't afford running that over the whole data stream (but who does that) because it's so much slower than symmetric encryption (which is why we have handshake protocols). But maybe do it once per block (or N blocks), adding cryptographic signatures to whatever's written. Blocks would be timestamped and these timestamps would be included in the signature too[0].
I could imagine, booting, without the password, would give you read-only access. Without password, the FS can only access the public key. The read operation uses this key to check the signatures on whatever blocks it's called to read. The write operation cannot be used to write any valid blocks, because it can't sign them without the private key (you can still trash blocks by overwriting them with invalid data, but you could do that anyways). Booting with a password allows the FS to decrypt the private key, allowing both read and write access.
Basically you'd have an encrypted FS, with the encryption left off but the verification left on.
For a Geeksquad-style attack you even get another layer of protection because without the password, the whole system is read-only. The "evil website put CP in my browser cache" attack is still possible because you'd be logged in, however in that case, at least you got verifiable timestamps on the written blocks, as well as your browser history, that can be analysed to show there was no intent to get, save or view this data.
I think this could be made to work in concept, in theory. Question is if you'd really want to use it though, authenticated verifiable timestamps on all your data, can also be a liability. Because people who "got nothing to hide" are just unaware that even they in fact, do. It means that for whatever you do on your computer, whoever can access the harddisk, can verify that whatever is on it was done by you, and only by you, as well as an undeniable proof of when it was done. That means zero privacy. Forward secrecy won't help here, because the whole point (verifiable authenticated timestamps) is about not having it. It may be nice for certain company laptops, however if it was my own machine, I'd prefer full-disk encryption, get the same protection and the privacy.
[0] while at it, why not also tag it with other metadata, such as origin (local or remote / where) and the process or application that issued the write command
Where is the key stored? Itll have to be in memory so that means it can be extracted from there if the pc is on. If the pc is off then things change. But this discussion assumes the attacker can place files on the system which means they can tamper with possibly timestamps blocks. If the system is encrypted and off then they can't add files and obviously not tamper with blocks either.
Besides, a "smart" Geeksquad employee could just backdate the comptuer's clock or manipulate the file creation time directly to make it look like the image was placed there when the owner had the computer in his posession.