Guessing they're the same, but not 100% sure.
UPDATE: My mistake for not clearly stating the it would be assumed the keys per-file, or for a whole volume, would be the exact same -- not to mention the encryption method use would be the exact same. The only difference is if it's executed on a per-file basis, or on a collection of files.
They definitely are not the same thing.
Consider what you learn from having a disk encrypted compared to unencrypted. When it's unencrypted it leaks a large amount of information. How much space is available? How much is used? What files exist on disk? Etc.
However, with each file encrypted, it's possible to use different keys per file, so if one key is compromised the other files are potentially safe. If the disk is encrypted then one key in theory unlocks everything.
More or less secure is relative to what you are trying to protect against. FDE won't protect against a curious child who already has an account on the system, but it would protect against someone walking away with the disk. File level encryption will protect against a child trying to read or write to the file, but if the key is stored on disk and someone walks away with the disk, the files are readable.
File based encryption techniques normally leak a lot of meta-information. File name, modification time, file size, etc. They also also lend themeslves to more cribs. Consider too that your temp files need to be encrypted, as does your swap.
OTOH, your backup software is accessing encrypted files... backing up encrypted data. Pros and cons to that too.
There are lots of disadvantages, and some advantages. Any particular implementation you're thinking of?
In theory, per file is weaker, since you give the attacker potentially valuable information on every file versus one giant encrypted disk (where an attacker has no idea whether the disk has any files on it or not). In practice, both are strong. Personally for sensitive data, I'll encrypt the sensitive file (e.g., a keepass database) on an encrypted disk -- that way when my system is running (and the system can read the unencrypted disk) the sensitive file is still protected (unless I've specifically opened it); and if my disk was stolen or someone tried changing data on my hard drive from a live cd, the data as a whole would be protected.
From file sizes, modification times and other meta-data, the attacker may be able to match some standard system files with their original versions and this information could in principal be of use in a known-plaintext attack. However, modern ciphers try and prevent against this type of attack by using large random and unique initialization vectors (among other techniques); however note the weakness in say WEP wireless encryption fundamentally was due to short IVs (only 24 bits) so only about 2^12 ~4096 messages needed to be captured before the same IV reappeared (so from guessing one plaintext you can recover other plaintexts).
There could also be extra information that an attacker could obtain from file sizes/times on the per file method even if they can't decrypt them; e.g., you could tell by the number of files/accessed date if people are currently actively working on a project or not, etc.
