This is the mail archive of the
mailing list for the Cygwin project.
RE: Using du.exe to calculate disk usage on a Microsoft cluster server
- From: Will Beldman <webmaster at bethel-crc dot ca>
- To: cygwin at cygwin dot com
- Date: Fri, 07 Jul 2006 17:16:24 -0400
- Subject: RE: Using du.exe to calculate disk usage on a Microsoft cluster server
- References: <44AECB27.firstname.lastname@example.org>
1. I have explained how I got long filenames (From another message):
"I don't own the files. One example is 259 characters long. They are
caused by users who have chosen to name their files the same thing as
the first sentence of their MS Word doc."
2. Most of the text you have quoted was my first message sent in. Some
of my follow ups helped explain your questions I'm sure.
3. Understand I cannot simply give out the names of offending files. I
am already standing on the borderline traversing other user's private
files let alone share the names online. Nonetheless, do not concern
yourself with these issues. The one I care about is the fts_read which
kills du. Even in the worst case, I would at least like to see du keep
going through other files until there are none left to do.
Some of my other responses are below:
On 07 July 2006 15:38, Will Beldman wrote:
> The problem is still here.
> As a refresher, here's the original problem:
Still lacking in useful information. You *still* haven't told us HOW on
earth you managed to get impossibly long file names, you *still* haven't
us the names of any directories that have failed.
> I need to determine disk usage for each directory on a Microsoft cluster
> server. As a linux junkie, du is *the* tool for automating this kind of
> stuff so I installed cygwin, mapped some drives and tried to schedule
> the utility to run at night. However, I get a lot of errors thrown back
> such as:
> 1. "No such file or directory" - Which tends to appear on weird
> filenames (like with spaces or ' or some other character) or when I
> don't have permission to access the drive (but that's something I can
> 2. "File name too long" - Which it is, but I'd hope there is some way to
> get around this
> 3. "du: fts_read failed: Permission denied" - That's the last error
> message I get. The program seems to crash at this point.
> I've seen no such issue in Linux and Google responses to the third error
> are rare and unhelpful.
> My question to the list is:
> 1. Is there a way to eliminate the errors above (especially the third so
> it can at least complete)
The answer is the same as before, since you have supplied none of the
further information which would have allowed a more detailed answer. You
might try using a mountpoint to shorten some of the prefix of the overly
filenames. I *still* don't understand how it is possible for your users to
create files with names that are longer than the maximum filename length
windows permits - this is a limitation of the windows OS and filing system,
not one that cygwin imposes.
> 2. Has anyone else found a solution which will properly report the
> amount of disk space a particular directory is occupying? Something that
> is free and can be scheduled to run at night.
"ls -laRh | grep ^total" plus a bit of sed/cut/awk/readline and maths?
This is an excellent idea. I may fiddle with this if I can't get du to go.
> I actually do not think the problem is escaping characters or spaces.
Well, you're the only one with any basis to make that guess, since you
haven't told us any of the failing names, just given us guesses about what
sort of characters might or might not be causing the problem. None of the
rest of us have any of the information that you are withholding.
> There are other files and directories which can use spaces no problem.
> It must be actual permission problems which I can fix.
Well, why don't you *look* at the permissions? None of us can see
you haven't told us anything about them.
I'm not the Windows admin and don't have any expertise or authority on
this windows system. I can get these problems hammered out with my
colleague I'm sure, I just need to take care of the fts_read problem.
> The command I am running is:<snip>
> du -sh /cygdrive/s/*
> This is because I want to know the size of the first level directories
> under the S drive. I will try
> du -sh /cygdrive/s
> to see if I get the same errors, but that will not fulfill my
Hmm, it's possible that some special character could be fooling the
Try opening a bash shell, then enter the command "bash -x", then enter the
command "du -sh /cygdrive/s/*". Bash will echo back the fully
expanded-and-quoted version of the command before it tries to run it;
look at it and see if it makes sense. Cut and paste it into a text
chop the line in half at the middle and try each subpart of the list of
in a du command until you've narrowed in on part of the command line that
triggers the problem; then tell us what it says.
I cannot do this manually during the day or the helpdesk and the admins
will lynch me, but I might try to play with this in the future. I might
just do #!/bin/bash -x or whatever. I'll notify you all if the results
don't make sense.
> Can anyone tell me under what circumstance the message
> du: fts_read failed: Permission denied
> would come up. I should be able to troubleshoot things from there if
> only I knew what that error message is really complaining about.
Which part of "Permission denied" don't you get, "permission" or
Ok, let me be explicit: the *exact* circumstances under which the message
"du: fts_read failed: Permission denied" would come up are when a) du has
called fts_read, and b) fts_read has returned an error value, because c)
underlying implementation of fts_read called one of the Win32 file
and d) that function returned error code 5, ERROR_ACCESS_DENIED.
Thanks. For some reason, it didn't hit me that fts_read was a system
function and not a generic error message. I'll do some more fiddling
with it and notify you all if I find anything useful.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html