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: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Fri, 7 Jul 2006 16:54:45 +0100
- Subject: RE: Using du.exe to calculate disk usage on a Microsoft cluster server
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 shown
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 fix)
> 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 long
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 that
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?
> 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 them and
you haven't told us anything about them.
> The command I am running is:
> 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 requirements.
Hmm, it's possible that some special character could be fooling the quoting.
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; take a
look at it and see if it makes sense. Cut and paste it into a text file, then
chop the line in half at the middle and try each subpart of the list of files
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.
> 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 "denied"?
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) the
underlying implementation of fts_read called one of the Win32 file functions
and d) that function returned error code 5, ERROR_ACCESS_DENIED.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html