Mail Archives: cygwin/2006/01/02/13:06:49
Eric Blake wrote:
> According to Fred Ma on 12/30/2005 1:20 PM:
>>When I repeatedly issue "du -sk ." within seconds of each other, the
>>results are different, and there is no process running that could be
>>changing the contents of the directory. Here is an illustrative
>>session:
>
> du can only report what the OS tells it. If it shows increasing numbers,
> then it was very likely that some process was consuming disk space in that
> directory (in spite of your claims to the contrary).
>
>>I am using an installation that is not quite up-to-date, but haven't
>
> "Not quite" is an understatement - cygwin is at 1.5.18; your version is
> missing a year and a half of bug fixes.
>
>>Since upgrading is nontrivial for me at present, I was trying to find
>>a history of release notes to see if this problem has been solved in
>>the cygwin versions since my current one. A search of the archives
>>revealed a confusion with blocking factors in the late 90's, but not
>>the same problem. Thanks for any other information about this. In
>>particular, if there is an on-line history of release notes that
>>captures this, that would be even better. Even if it does not
>>capture this, such a set of notes would be very useful.
>
> Browse the archives of the cygwin-announce list to see relevant changes
> announced for each software upgrade (for this email, that would include
> searching for mail with cygwin or coreutils in the subject):
> http://cygwin.com/ml/cygwin-announce/
>
> For particular programs, you can often find an online repository of
> changes. For example, cygwin changes are tracked here:
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog?cvsroot=src
>
> And many programs maintain a condensed version of user-visible changes.
> For example, coreutils changes that have happened since sh-utils,
> fileutils, and textutils here:
> http://cvs.savannah.gnu.org/viewcvs/coreutils/NEWS?rev=1.354&root=coreutils&view=markup
>
> Google can be your friend, after all.
Google is a good tool, I used it extensively before posting.
After doing more of that, and
perusing the links you provided, I'm not able to find a fix that might explain
the time-varying nature of du's reported numbers. It is somewhat repeatable in
the sense that if I don't issue "du -sk ." for some time, and then repeatedly
issue it, the first try is always low, and subsequent tries always settle on
450. It could very well be the interaction of du with the OS e.g hypothetically,
if the OS returns numbers right away before it finishes tallying, perhaps the first
attempts yields a premature total. For me to understand the possible causes, I'd
have to become much more familiar with Cygwin, du, and windows 2000. Rather than
speculating further, I'll take the steady-state result and upgrade at my first
opportunity. Thank you for the links.
Fred
--
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 -