Linus, please do a
bk pull http://linux-ntfs.bkbits.net/ntfs-2.6
Thanks!
This fixes the erroneous "du" and "stat" output people reported on ntfs
partitions containing compressed directories.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/, http://www-stu.christs.cam.ac.uk/~aia21/
===================================================================
This will update the following files:
Documentation/filesystems/ntfs.txt | 3 +++
fs/ntfs/ChangeLog | 8 ++++++++
fs/ntfs/Makefile | 2 +-
fs/ntfs/inode.c | 4 ++--
4 files changed, 14 insertions(+), 3 deletions(-)
through these ChangeSets:
<[email protected]> (04/01/19 1.1474.98.1)
Fix minor bug in handling of compressed directories that fixes the
erroneous "du" and "stat" output people reported.
diff -Nru a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
--- a/Documentation/filesystems/ntfs.txt Mon Jan 19 14:11:25 2004
+++ b/Documentation/filesystems/ntfs.txt Mon Jan 19 14:11:25 2004
@@ -272,6 +272,9 @@
Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
+2.1.6:
+ - Fix minor bug in handling of compressed directories that fixes the
+ erroneous "du" and "stat" output people reported.
2.1.5:
- Minor bug fix in attribute list attribute handling that fixes the
I/O errors on "ls" of certain fragmented files found by at least two
diff -Nru a/fs/ntfs/ChangeLog b/fs/ntfs/ChangeLog
--- a/fs/ntfs/ChangeLog Mon Jan 19 14:11:25 2004
+++ b/fs/ntfs/ChangeLog Mon Jan 19 14:11:25 2004
@@ -20,6 +20,14 @@
sufficient for synchronisation here. We then just need to make sure
ntfs_readpage/writepage/truncate interoperate properly with us.
+2.1.6 - Fix minor bug in handling of compressed directories.
+
+ - Fix bug in handling of compressed directories. A compressed
+ directory is not really compressed so when we set the ->i_blocks
+ field of a compressed directory inode we were setting it from the
+ non-existing field ni->itype.compressed.size which gave random
+ results... For directories we now always use ni->allocated_size.
+
2.1.5 - Fix minor bug in attribute list attribute handling.
- Fix bug in attribute list handling. Actually it is not as much a bug
diff -Nru a/fs/ntfs/Makefile b/fs/ntfs/Makefile
--- a/fs/ntfs/Makefile Mon Jan 19 14:11:25 2004
+++ b/fs/ntfs/Makefile Mon Jan 19 14:11:25 2004
@@ -5,7 +5,7 @@
ntfs-objs := aops.o attrib.o compress.o debug.o dir.o file.o inode.o mft.o \
mst.o namei.o super.o sysctl.o time.o unistr.o upcase.o
-EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.5\"
+EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.6\"
ifeq ($(CONFIG_NTFS_DEBUG),y)
EXTRA_CFLAGS += -DDEBUG
diff -Nru a/fs/ntfs/inode.c b/fs/ntfs/inode.c
--- a/fs/ntfs/inode.c Mon Jan 19 14:11:25 2004
+++ b/fs/ntfs/inode.c Mon Jan 19 14:11:25 2004
@@ -1,7 +1,7 @@
/**
* inode.c - NTFS kernel inode handling. Part of the Linux-NTFS project.
*
- * Copyright (c) 2001-2003 Anton Altaparmakov
+ * Copyright (c) 2001-2004 Anton Altaparmakov
*
* This program/include file is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as published
@@ -1046,7 +1046,7 @@
* sizes of all non-resident attributes present to give us the Linux
* correct size that should go into i_blocks (after division by 512).
*/
- if (!NInoCompressed(ni))
+ if (S_ISDIR(vi->i_mode) || !NInoCompressed(ni))
vi->i_blocks = ni->allocated_size >> 9;
else
vi->i_blocks = ni->itype.compressed.size >> 9;
===================================================================
This BitKeeper patch contains the following changesets:
1.1474.98.1
## Wrapped with gzip_uu ##
M'XL( (_E"T ]U7:V_B.!3]3'[%7>9+NR."G7>0&)4I[0R:;J>"Z6JE[0J9
MQ(&H28QB V65'[]V4@KEH2VHLQ\VH 3R.-?WW'/LFP]PSVG>JI&8&%C[ %\9
M%ZU:0#)!1GI&A3S59TR>:DY82IOE;<U,1+QAZ(XFK]X1$4Q@3G/>JF'=?#DC
MEE/:JO6OOMS?=/J:UF[#Y81D8SJ@ MIM3;!\3I*07Q Q25BFBYQD/*6"Z %+
MBY=;"P,A0WYL[)K(=@KL(,LM AQB3"Q,0V18GF.MT=0@=<;#1&?Y^#6,A3#R
ML8]<TR],!R-+ZP+6L>5:NN_I&)#51+B)?<!FR_!;MOL1H19"4*9\L68$/EK0
M0-IG>-\4+K4 KN,G2..,Y3":C2'.0&*$29R-@44@0:<YY9R&$,8Y#63XF'(0
M$R(@BI_*GU2"T#QG&64S#O5P5@>) '4NB*@#FXGI3,"4LFE"(:=3E@L:ZMHW
M,&UL&=K=ND1:X\A-TQ!!VB?X_*V(>"F0YF_DD49Q0@OLNTB2CY&)?-LOD/SC
M%A$-\,C&,G"(S-$NS;LP50VQCTW#M\W"\"1J%;'+@EE*Y9,B9EE3W<R77-"T
M0M#%D]@S!H0+UT8.=5%D4&<4CLS1[B#>@+PU+,M!GO.:"%G1D.K!/AZL8A2$
M9N0Y@>.%*/!=XS 1*YBM@([A>_[K@%49;]AX7]I.$49.Y!,LLZ>1Z4;6X9!K
MH.V@R+/LTM7_SI"R^SL623NQ2"96FVN;EE68ECR6_K?0CO'-@\8W?Y;Q[Z<A
M$;2<164*RI&5C+Y#(U^47^FPNS=P?8)O>X9K@:D9.M:=EE9KO,<L5(,3IB&E
MIAWA/8OG1&7O:F6OLC>E8=A8$E\N#89_A#:\GZR-EP$K=53VVU+'3FHGB<$
MK]("G*0$77M8:>CMSP!T-BXI]:RN+B'FD#$A94*29+D)P!DL)C2#!04N"R!E
M!XU/\7"4L."1*XPHIDFHHI)]<26RFD_5XPN:EQA"C3*6.LY9NI)QQK(&?8IY
M>:U"S&(91[4W^AI6Y_'?$F@2R\YG3.92UC)KEBH$><,L$5S799K7DLI-V\C@
M&5L 219DR6'&:0DN,V6!K'DX5*B*T4UKK-;#+6<<M=H>]L7F:OO*%I[C^Z4M
M7/L(5V!HX/]HQJSZ@0.>6*5U@B6Z'F"MIW97?_SH=X:7US>=+P-H0Z-[^^-Z
M,/S]JC_H?;]M/]1+VSS47U7K>='>*M91'8%&'J?I11B/*5-T_;DB\Z]]G8'D
M#7F20-LV"MGD>FXUE2'GB*(9T##^7_UMU2,=T,8S>Z=(PU+24#OX%2[9=)G'
MXXF L^ <)"FXH9HFZ&2"9=!)!)F2/"6/;*YUY=N'KQY]/M;B",X&P]Z@V^N?
MS=7T,DSEF,ZA*."7VU[&+E^X.<OB\_/U>U<PH7*VFZ5M.[!-%+A8^P>,6Q*K
$T0T
On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> This fixes the erroneous "du" and "stat" output people reported on
> ntfs partitions containing compressed directories.
Thanks for the quick patch. There are still problems with the reported
disk usage. I use as an example the file win.ini. With the 2.4.24
kernel I get the following results:
$ ls -l win.ini
-r--r----- 1 root staff 399 Jan 27 2003 win.ini
$ stat win.ini
File: "win.ini"
Size: 399 Blocks: 2 IO Block: 1024 Regular File
Device: 305h/773d Inode: 1023 Links: 1
Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 50/ staff)
Access: Thu Jan 15 15:34:09 2004
Modify: Mon Jan 27 18:54:00 2003
Change: Sun Sep 22 07:23:44 2002
$ du -h win.ini
1.0k win.ini
But, under the 2.6.1 kernel:
$ ls -l win.ini
-r-xr-x--- 1 root staff 399 Jan 27 2003 win.ini
$ stat win.ini
File: "win.ini"
Size: 399 Blocks: 0 IO Block: 4096 Regular File
Device: 305h/773d Inode: 1023 Links: 1
Access: (0550/-r-xr-x---) Uid: ( 0/ root) Gid: ( 50/ staff)
Access: Thu Jan 15 15:34:09 2004
Modify: Mon Jan 27 18:54:00 2003
Change: Mon Jan 27 18:54:00 2003
$ du -h win.ini
0 win.ini
Now, surely the 2.4.24 kernel is reporting the more accurate disk usage
since with 2.6.1 it reports 0 blocks (vice 2).
Thanks in advance,
--
David Sanders
[email protected]
On Wednesday 21 January 2004 01:24 pm, David Sanders wrote:
> On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> > This fixes the erroneous "du" and "stat" output people reported on
> > ntfs partitions containing compressed directories.
>
> Thanks for the quick patch. There are still problems with the
> reported disk usage. I use as an example the file win.ini. With the
> 2.4.24 kernel I get the following results:
> $ ls -l win.ini
> -r--r----- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 2 IO Block: 1024 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 50/
> staff) Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Sun Sep 22 07:23:44 2002
>
> $ du -h win.ini
> 1.0k win.ini
>
> But, under the 2.6.1 kernel:
> $ ls -l win.ini
> -r-xr-x--- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 0 IO Block: 4096 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0550/-r-xr-x---) Uid: ( 0/ root) Gid: ( 50/
> staff) Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Mon Jan 27 18:54:00 2003
>
> $ du -h win.ini
> 0 win.ini
>
> Now, surely the 2.4.24 kernel is reporting the more accurate disk
> usage since with 2.6.1 it reports 0 blocks (vice 2).
>
> Thanks in advance,
Also, chkdsk in winnt4 reports the cluster size in 512 bytes. The ntfs
driver seems to think the size is 4096 bytes (or 1024 bytes in 2.4
kernel). Thanks,
--
David Sanders
[email protected]
On Wednesday 21 January 2004 01:24 pm, David Sanders wrote:
> On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> > This fixes the erroneous "du" and "stat" output people reported on
> > ntfs partitions containing compressed directories.
>
> Thanks for the quick patch. There are still problems with the
> reported disk usage. I use as an example the file win.ini. With the
> 2.4.24 kernel I get the following results:
> $ ls -l win.ini
> -r--r----- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 2 IO Block: 1024 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 50/
> staff) Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Sun Sep 22 07:23:44 2002
>
> $ du -h win.ini
> 1.0k win.ini
>
> But, under the 2.6.1 kernel:
> $ ls -l win.ini
> -r-xr-x--- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 0 IO Block: 4096 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0550/-r-xr-x---) Uid: ( 0/ root) Gid: ( 50/
> staff) Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Mon Jan 27 18:54:00 2003
>
> $ du -h win.ini
> 0 win.ini
>
> Now, surely the 2.4.24 kernel is reporting the more accurate disk
> usage since with 2.6.1 it reports 0 blocks (vice 2).
>
> Thanks in advance,
I thought perhaps stat -f output would be usefull:
>From WINNT 4.0
stat -f win.ini
File: "win.ini"
ID: 1078931058 ( 404F2E72) Namelen: 255 Type:
NTFS
Blocks: Total: 8385866 Free: 3808839 Available: 3808839 Size:
512
Inodes: Total: 8385866 Free: 3808839
>From 2.4.24 kernel:
File: "win.ini"
ID: 0 0 Namelen: 255 Type: ntfs
Blocks: Total: 8385866 Free: 3808930 Available: 3808930 Size:
512
Inodes: Total: 40642 Free: 0
>From 2.6.1 kernel:
File: "win.ini"
ID: 404f2e72 90404f42 Namelen: 255 Type: ntfs
Blocks: Total: 1048233 Free: 476116 Available: 476116 Size:
4096
Inodes: Total: 40642 Free: 95
--
David Sanders
[email protected]
On Wed, 2004-01-21 at 18:24, David Sanders wrote:
> On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> > This fixes the erroneous "du" and "stat" output people reported on
> > ntfs partitions containing compressed directories.
>
> Thanks for the quick patch. There are still problems with the reported
> disk usage.
No there are not. It is a feature, not a bug. (-: I will explain
below...
> I use as an example the file win.ini. With the 2.4.24
> kernel I get the following results:
> $ ls -l win.ini
> -r--r----- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 2 IO Block: 1024 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 50/ staff)
> Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Sun Sep 22 07:23:44 2002
>
> $ du -h win.ini
> 1.0k win.ini
This is wrong. The file size is 399 bytes, and knowing from my own
systems, win.ini is a resident file (which is consistent with the small
size). This means the file doesn't occupy any disk blocks at all. All
the data is stored inside the on-disk inode itself (that is the MFT
record in NTFS speak).
Further, the table of inodes (the system file $MFT) already has its own
size (do "ls -l \$MFT" or "du \$MFT" in the main NTFS directory and you
will see it together with its size).
The size of the inode itself (1024 bytes) is already accounted for in
the size of the $MFT system file (the table of inodes).
Since the 399 bytes of win.ini are part of those 1024 bytes we would be
counting them twice if we were to give them in the "Blocks:" field of
stat, which is what "du" uses to calculate sizes.
So by returning the above "Blocks: 2", the old NTFS driver (which is
what you used by using an unpatched 2.4.24 kernel), du will actually
tell you that you are using more space than you are as it would count 2
Blocks from win.ini and then the same 2 Blocks from $MFT which clearly
is silly. (-:
> But, under the 2.6.1 kernel:
> $ ls -l win.ini
> -r-xr-x--- 1 root staff 399 Jan 27 2003 win.ini
>
> $ stat win.ini
> File: "win.ini"
> Size: 399 Blocks: 0 IO Block: 4096 Regular File
> Device: 305h/773d Inode: 1023 Links: 1
> Access: (0550/-r-xr-x---) Uid: ( 0/ root) Gid: ( 50/ staff)
> Access: Thu Jan 15 15:34:09 2004
> Modify: Mon Jan 27 18:54:00 2003
> Change: Mon Jan 27 18:54:00 2003
Correct. No disk blocks are occupied as explained above.
> $ du -h win.ini
> 0 win.ini
That is correct. To quote from the man page for "du":
"Summarize disk usage of each FILE"
It is "disk usage" not "file size" and the file "win.ini" does not use
any disk space as explained above.
> Now, surely the 2.4.24 kernel is reporting the more accurate disk usage
> since with 2.6.1 it reports 0 blocks (vice 2).
Nope. Sometimes things are not what they seem. (-:
Hope this clears the confusion up.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
On Wed, 2004-01-21 at 19:14, David Sanders wrote:
[snip]
> Also, chkdsk in winnt4 reports the cluster size in 512 bytes. The ntfs
> driver seems to think the size is 4096 bytes (or 1024 bytes in 2.4
> kernel).
To quote from the man page for "stat(2)":
"The value st_blksize [which is the "IO Block:" field in the stat(1)
output you are referring to above] gives the "preferred" blocksize for
efficient file system I/O. (Writing to a file in smaller chunks may
cause an inefficient read-modify-rewrite.)"
And this is what it is saying. In the new NTFS driver doing any form of
i/o is most efficient if it is done in 4096 byte chunks, i.e. a single
read or write of 4096 bytes will be faster than reading or writing a
single byte 4096 times over. The old NTFS driver didn't really care.
IMO 512 would have been a better value to 1024 as the driver uses 512
byte i/o requests but it doesn't really matter much.
To summarise: the st_blksize/"IO Block" has absolutely nothing at all to
do with the cluster size of the NTFS volume.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
On Wed, 2004-01-21 at 19:38, David Sanders wrote:
[snip]
> I thought perhaps stat -f output would be usefull:
> From WINNT 4.0
> stat -f win.ini
> File: "win.ini"
> ID: 1078931058 ( 404F2E72) Namelen: 255 Type:
> NTFS
> Blocks: Total: 8385866 Free: 3808839 Available: 3808839 Size:
> 512
> Inodes: Total: 8385866 Free: 3808839
Now _that_ is complete and utter garbage! At an inode size of 1024
bytes you physically cannot fit 8385866 inodes into that volume and I am
sure there aren't that many inodes... And the number of free inodes
quoted is garbage, too as you could not add that many inodes as you
would run out of space half way through. Whoever wrote "stat" from
Windows was smocking crack... Or alternatively they failed to read the
man page for statfs on a Unix/Linux system and had no clue as to what
the fields mean...
> From 2.4.24 kernel:
> File: "win.ini"
> ID: 0 0 Namelen: 255 Type: ntfs
> Blocks: Total: 8385866 Free: 3808930 Available: 3808930 Size:
> 512
> Inodes: Total: 40642 Free: 0
That sounds a lot more sane. Thought the free inodes output is just
seto to zero as is the ID.
> From 2.6.1 kernel:
> File: "win.ini"
> ID: 404f2e72 90404f42 Namelen: 255 Type: ntfs
> Blocks: Total: 1048233 Free: 476116 Available: 476116 Size:
> 4096
> Inodes: Total: 40642 Free: 95
This is the most sensible output, quoting the correct ID, the blocks count
is about the same as the output from the other stat runs as the block size
is 8 times bigger hence the number of blocks is 8 times smaller, and the
inodes count is sensible. Where as the old driver simply returns 0 the new
driver returns how much space is left free inside the $MFT at its present
size. So even if you had run out of disk space you could still create up
to 95 inodes on the volume before needing to free up space (as long as there
was space in the directory indices for them and as long as they were very
small so their data would be stored in the inode).
The free inodes count is still not quite right as $MFT can be extended
(until you run out of space or you hit 2^48 inodes) so the number of inodes
that could potentially be created is equal to = 95 + (the current free space
in bytes) / 1024 in the above example but more realistically you will not
be able to create that many because files will take up space on disk,
directories will do, too, etc, so the actual value will be somewhere in
between. So when I wrote the new driver I decided to use the number of
unused inodes in the current $MFT, which in this case is 95, as the most
sensible output and just take the free inodes count to mean "at least so
many inodes can be created".
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
On Thursday 22 January 2004 04:20 am, you wrote:
> On Wed, 2004-01-21 at 18:24, David Sanders wrote:
> > On Monday 19 January 2004 09:15 am, Anton Altaparmakov wrote:
> > > This fixes the erroneous "du" and "stat" output people reported
> > > on ntfs partitions containing compressed directories.
> >
> > Thanks for the quick patch. There are still problems with the
> > reported disk usage.
>
> No there are not. It is a feature, not a bug. (-: I will explain
> below...
>
> > I use as an example the file win.ini. With the 2.4.24
> > kernel I get the following results:
> > $ ls -l win.ini
> > -r--r----- 1 root staff 399 Jan 27 2003 win.ini
> >
> > $ stat win.ini
> > File: "win.ini"
> > Size: 399 Blocks: 2 IO Block: 1024 Regular File
> > Device: 305h/773d Inode: 1023 Links: 1
> > Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 50/
> > staff) Access: Thu Jan 15 15:34:09 2004
> > Modify: Mon Jan 27 18:54:00 2003
> > Change: Sun Sep 22 07:23:44 2002
> >
> > $ du -h win.ini
> > 1.0k win.ini
>
> This is wrong. The file size is 399 bytes, and knowing from my own
> systems, win.ini is a resident file (which is consistent with the
> small size). This means the file doesn't occupy any disk blocks at
> all. All the data is stored inside the on-disk inode itself (that is
> the MFT record in NTFS speak).
>
> Further, the table of inodes (the system file $MFT) already has its
> own size (do "ls -l \$MFT" or "du \$MFT" in the main NTFS directory
> and you will see it together with its size).
>
> The size of the inode itself (1024 bytes) is already accounted for in
> the size of the $MFT system file (the table of inodes).
>
> Since the 399 bytes of win.ini are part of those 1024 bytes we would
> be counting them twice if we were to give them in the "Blocks:" field
> of stat, which is what "du" uses to calculate sizes.
>
> So by returning the above "Blocks: 2", the old NTFS driver (which is
> what you used by using an unpatched 2.4.24 kernel), du will actually
> tell you that you are using more space than you are as it would count
> 2 Blocks from win.ini and then the same 2 Blocks from $MFT which
> clearly
>
> is silly. (-:
> > But, under the 2.6.1 kernel:
> > $ ls -l win.ini
> > -r-xr-x--- 1 root staff 399 Jan 27 2003 win.ini
> >
> > $ stat win.ini
> > File: "win.ini"
> > Size: 399 Blocks: 0 IO Block: 4096 Regular File
> > Device: 305h/773d Inode: 1023 Links: 1
> > Access: (0550/-r-xr-x---) Uid: ( 0/ root) Gid: ( 50/
> > staff) Access: Thu Jan 15 15:34:09 2004
> > Modify: Mon Jan 27 18:54:00 2003
> > Change: Mon Jan 27 18:54:00 2003
>
> Correct. No disk blocks are occupied as explained above.
>
> > $ du -h win.ini
> > 0 win.ini
>
> That is correct. To quote from the man page for "du":
>
> "Summarize disk usage of each FILE"
>
> It is "disk usage" not "file size" and the file "win.ini" does not
> use any disk space as explained above.
>
> > Now, surely the 2.4.24 kernel is reporting the more accurate disk
> > usage since with 2.6.1 it reports 0 blocks (vice 2).
>
> Nope. Sometimes things are not what they seem. (-:
>
> Hope this clears the confusion up.
>
> Best regards,
>
> Anton
Yes, I think that clears it up in my mind, but I think the output of du
is a little misleading to the uninitiated.
Thanks, David
--
David Sanders
[email protected]