As already mentioned by fgrieu in a comment, you seem to be mixing up the initialization vector for the cipher with the salt for the key derivation. They play similar roles — both are here to insure that different values of the IV/salt lead to different keys/ciphertext — but they are used in different ways and they have different security properties in this scenario.
When you generate a key from a password, the number of likely passwords is far less than the total number of possible keys. A pretty good password may have 44 bits of entropy; a password used in the wild tends to have a lot less. Compare to 128 bits of entropy in a randomly-generated AES-128 key. This makes the key space vulnerable to brute force search (“I'll derive the key for password1 and try to decrypt. Nope. swordfish? Nope. Tr0b4dor&3? Nope. Tr0b4dor&4? Win!”).
In order to mitigate this problem, deriving a key from a password must include two elements:
- Slowness, because spending .1s instead of .1ms to derive the key when the user types his password isn't a performance problem, but it multiplies the work needed by an attacker by 1000.
- Uniqueness, so that an attacker cannot precompute all the keys derived from likely passwords and then crack a lot of password-encrypted files by a simple table lookup.
The issues are the same as password hashing — and indeed most password hashing schemes are password-based key derivation algorithms.
To derive a key from a password, you need a password-based key derivation function, which includes a step of key stretching for slowness and uniqueness. The salt, which provides uniqueness, is an input to the KDF, alongside the password. bcrypt, PBKDF2 and scrypt are the three recommended password-based key derivation algorithms nowadays; scrypt has the nicest properties (it's less easy to brute-force with dedicated hardware) but is still a bit new.
The salt must be unique for everybody who uses the same KDF, not just among your files. The best way to ensure this is to have a sufficiently long random salt.
All message encryption algorithms use an IV or nonce to ensure that if you encrypt the same message twice, this isn't visible in the ciphertext (at least the algorithms that are semantically secure — it is occasionally useful to sacrifice this property in the interest of deterministic encryption but that applies to specialized scenarios). If you only ever encrypt one message with the same key, you don't need an IV — the standard thing to do in this case is to use an all-bits-zero IV.
If you only ever encrypt one file with the same key, you don't need an IV. Do consider that if you use the same key for multiple versions of the file, you should use an IV. You may want to derive a new key with a new salt in this situation, though.
rehash/generate the encryption key from the plain text password, could you clarify what you mean? $\endgroup$