[ANNOUNCEMENT] [1.7] Updated: coreutils-7.0-1

[Christian Franke]

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/