Rescued partition - inconsistent properties

[TJGeezer]

EDIT: I solved my problem, but still have no idea what conflicting numbers inside the same "Properties" box means or how Nemo could have come up with that. When I got the files copied onto other drivers, I deleted the partition, planted a new partition in Ext4 format instead of NTFS, and copied the achives back. Result: a "Properties" box that makes sense and no more problem. However, if anyone could suggest how Nemo came up with the inconsistent properties reported below, I'd love to see it.
Thanks, those who read my message. I guess it puzzled you too.
TJ
---------------------------------
ORIGINAL MSG:
f you guessed from the subject line that I don't know how to summarize this problem, you're right. Hope this is the right forum for this problem.

I'm running Mint 16 on an x86 64-bit desktop with plenty of storage and 4GB RAM. Low-end graphics card, USB 3.0/SATA 3 add-in card.

Setup: I was partitioning a new drive when a finger-stutter deleted a 2TB partition on another drive, holding archives and other files I need to keep but do not access frequently. The archive drive is a 2TB Fantom External HDD, USB2.0, NTFS, not used daily. I followed a rescue procedure using Parted and the partition reappeared with files apparently intact, all praise and free beer to the Parted team.

Problem: In Nemo, when I right-click and select Properties, it reports:
- Drive contains 325,297 items (and 417 hidden), totaling 1.3 TB
- 366.7 GB used
- 1.6 TB free

All utilities report about the same but are inconsistent - for example, df reports
Filesystem Size Used Avail Use% Mounted on
/dev/sdi1 1.9T 342G 1.5T 19% /media/tj/FantomHD

Clearly, 1.3 TB of files on a 2 TB drive does not leave 1.5 TB (or 1.6 TB) free. I'm not writing anything new to such a weird drive, needless to say. Those 417 hidden files are weird, too.

Questions:
(1) Do any of you have a clue what these inconsistencies mean? (I don't.)
(2) Is there a safe way to resolve the inconsistencies other than copying off the important archives and repartitioning from scratch? (If so, how?)
(3) In the meantime, are the archived files in danger?

All the files I've checked are intact. I'm proceeding to copy off the archives I can't afford to lose. I'd like to fix the problem without repartitioning if I can. Thanks for any and all suggestions!

[Fraoch]

Two possibilities:

1. NTFS. Although support in Linux is better than what it was, it's still not as good as ext4. In particular, you may see problems when drives get into trouble - shutdown improperly or rescued like this one was.

2. Parted may have done something odd. Nothing against Parted of course, but a lot can go wrong when you try to rescue deleted files like that. It may have had a slight hiccup along the way.

[Mute Ant]

(1) Do any of you have a clue what these inconsistencies mean? (I don't.)

The 'properties' reply is the result of a file manager looking at directory entries and adding up the reported file sizes. The sum may or may not be closely related to the definitely-free-for-use space after damage recovery, especially on a proprietory file system like NTFS.

(2) Is there a safe way to resolve the inconsistencies other than copying off the important archives and repartitioning from scratch? (If so, how?)

No. Copy is the only safe way to recover the files.

(3) In the meantime, are the archived files in danger?

As far as I know a drive asked to read does not try to change data, even if the request causes a read error. Writing to an inconsistent file system risks destroying some or all of the content.

And check each recovered file. Sure it says .jpg or .mp3 or .pdf on the end, and it's the right length, but does it display/play/open?