User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2
On 10/06/06 19:48, Robert Cerny wrote:
On 10.6.2006, at 1:11, Axel Luttgens wrote:
On 9/06/06 16:53, Černý Robert wrote:
Hi folks,
I usually use 'sudo du -sh /Volumes/*' to get occupied size on each
volume. However, I compared it to Finder's info and get completely
different results:
sudo du -sh /Volumes/
106 G /Volumes/Archive
Finder: 196GB
The contents of the drive are jpg images, saved using AFP, so I
believe the difference is probably in resource forks. Am I right?
That's rather strange.
Could you check the integrity of the volume (disk) mounted on /
Volumes/Archive?
Axel
Well,
the problem I'm talking about has its origin. I was backing up my
Archive using BRU to Sony AIT2 tape, which can hold 47GB and prepared
3 tapes. However, I was asked for 6 of them.
If you allow, I'll first come back to your original question.
I just created here a BBEdit file with 5000 characters in the text:
luttgens$ ls -al testfile
-rw-r--r-- 1 luttgens luttgens 5000 11 Jun 10:55 testfile
luttgens$ ls -al testfile/..namedfork/rsrc
-rw-r--r-- 1 luttgens luttgens 1710 11 Jun 10:55
testfile/..namedfork/rsrc
That file thus has 5000 bytes in its data fork and 1710 bytes in its
resource fork.
Getting info for that file from the Finder:
12 Kb on disk (6710 bytes)
That's consistent with an allocation block size of 4 Kb on HFS+ volumes
(2 blocks for the data fork, 1 block for the resource fork); 12 Kb are
needed on the disk, even if only 6710 bytes are really in use.
Now, let's use du:
luttgens$ du -h testfile
12K testfile
So, du doesn't miss a file's resource fork.
On the other hand, du may miss other info: the volume header, the
catalog file, the extents overflow file, the attributes file, etc.
These data structures are maintained for organizing/accessing files on
the disk, without being themselves accessible as regular files.
They thus take some room on the disk, and this should be reported by the
df command (or by the Finder when asked about a whole volume).
For example, I get here:
luttgens$ sudo du -sk /Volumes/Data
32896340 /Volumes/Data
luttgens$ df -k /Volumes/Data
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/disk0s5 51805272 33128336 18676936 64% /Volumes/Data
It appears that about 200 Mb are missed by du on my "Data" volume.
The discrepancy you reported (106 Gb vs 196 Gb, almost 100%!) really
looks somewhat excessive...
Could you tell us the output of du/df in your case?
As well as check your disk (with Disk Utility.app or with command diskutil)?