Essentially you want to know if the password is correct after the password is entered, but before files are accessed. Either option you came up with will detect incorrect passwords, and neither is worse than the other.
A method I used in the past was similar to your ideas, to encrypt a known string or block, then check it after. However I processed the block so that there was no longer a direct relationship with the key.
The 16 byte string is encrypted, hashed, then truncated down to 4 bytes and text encoded with Base64URL, leaving a 6 byte alphanumeric string. The same process is repeated on password entry, and the string is matched to determine if the password is correct. The string is stored with the salt and hashing parameters. I would suggest a warning be shown when the password is detected as incorrect, and you be given the option to use the generated key anyway, there may be a reason to use a different password than your usual.
The other thing I did differently was during file encryption. Instead of using the password generated key, a random key was generated to encrypt the data, then that was encrypted with the password generated key and stored with the file. That way the password could be changed without reencrypting the entire file, only the encrypted key needs to be changed.
Edit for additional explanation
can you explain your third paragraph better? (Please include in the explanation: Why use this long way, what are the advantages, why is Base64URL needed (instead of storing the bytes), why truncate to 4 bytes?)
Starting at the end, why 4 bytes? Because more are just not necessary. 4 bytes is 32 bits, which gives you a very good chance of a wrong password NOT generating the same value. The more bytes you store, an attacker would be more likely to determine the actual password, instead of one of the millions that generate the same check value. The less you store, the more likely an incorrect password will pass the test.
Why Base64URL instead of storing the bytes? Encoding allows it to be stored in a text readable format, as well as be written down or printed without conversion. Standard password hash formats use text readable encodings, PHC uses a variant of the modular crypt format with Base64 encoding. If you did not encode the values, they could potentially contain control characters like carriage return and line feed, and reading the values could no longer be done with a text editor. I like unpadded Base64URL because it gives more flexibility (you can put it in a URL, etc), the padding is not needed because there is no reason to decode it, it is either used as a direct input (encoded salts) or a comparison string.
Why use this long way, what are the advantages? The main advantage is that there is no longer a direct relationship between the key generated by the password and the check value. If there was ever a known plaintext shortcut attack on the cipher or a preimage attack on the hash function, the long way should should completely prevent either or even both of those.
Incidentally the long way is not long at all. Since you already have implemented a hash for PBKDF2 and a cipher for encryption, it should take only a line or 2 of code to generate the check value, Base64URL can usually be implemented in 1 line of code if you already have Base64 available. Pseudocode like this after you generate the key:
CheckValue = Base64URL(Truncate(Hash(Encrypt_ECB(0,key)),4))