HKDF doesn't require a salt. It does make the HKDF stronger, but in principle you can just use it without salt (or, if you're not sure, with an unreliable salt).
The salt is mainly there required when password-based encryption is used to protect against rainbow tables and identifying identical passwords. However, in this case with SIV mode you'd only be able to reliably detect identical files encrypted with the same password. The main problem seems to be the password based encryption itself.
Personally I would try and use asymmetric cryptography for this: encrypt the file using a public key (hybrid cryptography, encrypting or deriving a random AES key for each file) and protect the private key using a password and a real random salt. Then you can store the well-protected private key somewhere next to the file (or, preferably, somewhere more secure). You'd also not have to perform the PBKDF for each file, once you have the private key in memory.
Beware that many asymmetric algorithms are not secure against a full fledged quantum computer. So you might want to have another look if you want to protect your files against adversaries in the long term.
It should also be noted that, given a public key, anybody is able to encrypt. That could be a problem as an adversary may, for instance, swap or insert ciphertext without having a key.
Note that, if you remove time from the equation, that the full path is usually unique for each file. So if you'd hash that you'd have a pretty good deterministic salt - which you could also mix with a non-reliable salt. You should probably still store the salt as not to make decryption rely on that full path.
