LinuxQuestions.org - [SOLVED] df and du give different results on DVD filesystem

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - df and du give different results on DVD filesystem (https://www.linuxquestions.org/questions/linux-software-2/df-and-du-give-different-results-on-dvd-filesystem-4175534916/)

df and du give different results on DVD filesystem

On debian 7.5,

Code:

$ mount /dev/sr0 /DVD

$ df -h /DVD

Filesystem    Size    Used  Avail Capacity  Mounted on

/dev/sr0      6.8G    6.8G    0      100%    /DVD

$ du -h /DVD

25G  /DVD/VIDEO_TS

25G  /DVD

$ grep DVD /etc/fstab

/dev/sr0    /DVD    iso9660    ro,noexec,user,nodev 1 2

$

The disc is a recent commercial dual layer video DVD (Jack Ryan: Shadow Recruit), not a Blu-Ray. It plays properly; I just don't see why du gives such a different size to df - in fact, it seems to be almost 4 times what the DVD can hold.

Can anyone explain the difference?

Hi there,

Quote:

Originally Posted by Wocky (Post 5322382)

Code:

$ mount /dev/sr0 /DVD

$ df -h /DVD

Filesystem    Size    Used  Avail Capacity  Mounted on

/dev/sr0      6.8G    6.8G    0      100%    /DVD

$ du -h /DVD

25G  /DVD/VIDEO_TS

25G  /DVD

$ grep DVD /etc/fstab

/dev/sr0    /DVD    iso9660    ro,noexec,user,nodev 1 2

$

it's important to know that du works on a file level, while df works on a file system level. In other words, du examines the directory entries and considers the size of all the files listed in it, while df just looks at the control structures of the file system, which only partially makes sense for ISO9660 - at least this file system has no free blocks by definition.

And what you see is obviously a bad trick used by some DVD producers: They deliberately produce weird directory structures, for instance by referencing the same file multiple times (very much like hard-linking) or by creating bogus directory entries that do not reference a valid file at all but pretend gigabytes of data. Try a 'ls -la /DVD/VIDEO_TS' to see what I mean.
The only purpose I can think of is probably to discourage people from ripping the DVD contents, or to make it harder for them anyway.

The first DVD where I encountered this trickery was Wall-E, which seemed to have over 60GB of data ...

[X] Doc CPU

This directory scrambling of DVDs has been around for years. It is a copy protection scheme.

Hi there,

Quote:

Originally Posted by haertig (Post 5322530)

This directory scrambling of DVDs has been around for years. It is a copy protection scheme.

that's what I said.
However, as a copy protection method it is pointless, because assuming you beat CSS and these other little tricks, you can always rip the DVD into an ISO file - and suddenly you don't have to bother about this file system shit.

[X] Doc CPU

Quote:

Originally Posted by Doc CPU (Post 5322426)

Hi there,

it's important to know that du works on a file level, while df works on a file system level. In other words, du examines the directory entries and considers the size of all the files listed in it, while df just looks at the control structures of the file system, which only partially makes sense for ISO9660 - at least this file system has no free blocks by definition.

And what you see is obviously a bad trick used by some DVD producers: They deliberately produce weird directory structures, for instance by referencing the same file multiple times (very much like hard-linking) or by creating bogus directory entries that do not reference a valid file at all but pretend gigabytes of data. Try a 'ls -la /DVD/VIDEO_TS' to see what I mean.
The only purpose I can think of is probably to discourage people from ripping the DVD contents, or to make it harder for them anyway.

The first DVD where I encountered this trickery was Wall-E, which seemed to have over 60GB of data ...

[X] Doc CPU

This turned out to be the answer. I compared some of the files in the VIDEO_TS subdir, and, of 86 files, 38 were identical to at least five others. I ripped the DVD (I find it amusing that the very things done to discourage ripping actually encourage it) and replaced the copies with symbolic links. Playing the copy works as it should.