Mail Archives: cygwin/2008/12/16/15:19:15
Corinna Vinschen wrote:
>> [...]
>> Also, coreutils currently only sorts large directories, but cygwin reports
>> directory st_size as 0 regardless of directory size, so there is no way to
>> identify large directories up front.
>>
>
> Not quite. Did you call `ls -s' on cygwin's / directory lately? A snippet
> from mine on one of my machines look like this:
>
> 160 drwxrwx---+ 1 corinna vinschen 163840 Dec 16 10:13 bin
> 0 drwxrwx---+ 1 corinna vinschen 0 Apr 15 2008 cygdrive
> 0 drwxrwx---+ 1 corinna vinschen 0 Apr 30 2008 dev
> 12 drwxrwx---+ 1 corinna vinschen 12288 Dec 15 11:15 etc
> 4 drwxr-xr-x+ 1 corinna vinschen 4096 Jul 4 10:41 home
> 40 drwxrwx---+ 1 corinna vinschen 40960 Dec 8 11:58 lib
> 0 dr-xr-xr-x 8 corinna vinschen 0 Dec 1 2006 proc
> 0 drwxrwx---+ 1 corinna vinschen 0 Apr 15 2008 sbin
> 4 drwxrwxrwt+ 1 corinna vinschen 4096 Dec 15 16:35 tmp
> 4 drwxrwx---+ 1 corinna vinschen 4096 Dec 8 11:54 usr
> 0 drwxr-xr-x+ 1 SYSTEM Administrators 0 May 21 2008 var
>
> The size of a directory which you just created is 0. But big
> directories (like /bin), or directories which once were big (like /tmp)
> have a size which is a multiple of 4K. This size is what's returned by
> the NT function NtQueryInformationFile. I assume that a directory is
> created with one block in a pre-allocated area in the MFT or so, which
> explains size 0. When the dir grows, then normal FS blocks are added,
> so the size grows beyond 0. But actualyy I have no idea, so it could be
> entirely different. :)
>
>
On my XP SP2, st_size is always 0, even for large and fragmented
directories.
>>
>> Are there any file systems accessed by cygwin where sorting readdir()
>> results into inode order, rather than visiting contents in directory
>> listing or name order, provides a speedup by allowing less disk seek time
>> (or put another way, do the inode numbers presented by Cygwin for local
>> NTFS disks match disk seek order)? Conversely, are there any file systems
>> where taking the time to sort readdir() results is provably a waste (for
>> example, a ramdisk, where seek time is instant regardless of inode, or FAT
>> and NFS where inode numbers are synthesized with no correlation to disk
>> layout,
>>
>
> Interesting question. NTFS and FAT filesystems are name-sorted by
> default. AFAIK directory changes on FAT are done in-memory, resorted,
> and then written back as a whole block to disk.
XP does not sort a FAT directory.
Does this probably depend on Windows version?
Christian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -