[SOLVED] df and du give different results on DVD filesystem

Wocky · 02-23-2015, 11:39 PM

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?

Doc CPU · 02-24-2015, 02:45 AM

Hi there,

Quote:

Originally Posted by Wocky

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?

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

haertig · 02-24-2015, 08:09 AM

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

Doc CPU · 02-24-2015, 09:14 AM

Hi there,

Quote:

Originally Posted by haertig

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

Wocky · 02-25-2015, 03:25 PM

Quote:

Originally Posted by Doc CPU

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.