0

I work on an ext4 filesystem. I have doubts about the accuracy of a directory entry regarding the description of a file that I have copied from an NTFS filesystem and that might have spanned some bad sectors (but I am not sure). I now believe the file might have been truncated when copied from its source but that the directory entry in the ext4 filesystem does not reflect the now-truncated file size but rather kept the information of the file size from the NTFS filesystem table. I don't know if such a situation is possible, but I want to be sure the file is not truncated (unfortunately the file is in a proprietary format and I cannot just open the file to check it).

I run a dd command on the file toward /dev/null and it seemed to have "copied" as much as the original file size. However, I am now wondering whether the dd command used the meta data about the file size from the inode table, which would defeat the goal.

  • Can it be that after copying a file the inode table doesn't reflect the real size of what was actually copied? (I think I just did a click-and-drag in a file explorer)?
  • Is using the dd command a good option?
  • Are there metadata in the ext4 filesystem that could be used to independently check the size of the file and thus accuracy of the information in the inode table (I think about data integrity fields)?
1
  • 1
    To check the integrity maybe you can consider to use hash functions. Nov 12, 2022 at 19:22

1 Answer 1

1

So first of all, the untrustworthy filesystem involved here seems to be the originating, not the target file system. If the origin read nonsense, that nonsense gets "correctly" written to the target file, and there's nothing you could do about afterwards – for all that there is in information, that's how the original file was.

So, no, we can from a perspective of your use case rule out that data corruption of any form happened on the writing end. If anything, the data was read corruptedly.

Then:

kept the information of the file size from the NTFS filesystem table.

That's not how copying between file systems work. You make the target file, you write over the contents of the source file (either through reading the source and writeing to the target file, or through the copy_file_range system call), but the metadata is kept and structured by the target file system itself, which knows nothing about the original file. So, no, that does not happen.

Can it be that after copying a file the inode table doesn't reflect the real size of what was actually copied? (I think I just did a click-and-drag in a file explorer)?

No, or: very very unlikely. In ext4, the metadata (so, everything but the actual data) is actually journaled. In other words, metadata is either changed completely, or not at all.

For ext4, the default mode of how data is journaled relative to metadata is data=ordered (see man ext4); which means that data is written to the file system completely before the metadata gets updated. So, the one thing that could happen if your system, for example, loses power, is that the data write has happened, but the metadata has not. That would have the effect of the file size being less than what was copied, not more.

So, because the data is written before the metadata, and the metadata is correct, we can be sure that the data is correct. (again, garbage in, garbage out would still apply if the data on the source was corrupted)

Is using the dd command a good option?

no, because any program will get exactly the amount of data that the file system gives it. If the file system was corrupted and incorrectly thinking the file was longer, it would give out some data that it incorrectly attributed, so that your dd wouldn't be any wiser. Not because it had any metadata access, but because the very error you want to catch with it would mean it would look like the error was not there, for all that dd cares about.

Are there metadata in the ext4 filesystem that could be used to independently check the size of the file and thus accuracy of the information in the inode table (I think about data integrity fields)?

No, unless you want to have a second copy of the filesystem metadata, which is exactly what you're asking for to be correct.

Ext4 is, as mentioned above, a journaling file system, which guarantees that metadata writes are complete or did not happen.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .