Mail Archives: cygwin/2006/07/07/17:16:25
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:
DaveK wrote:
> 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?
<snip>
This is an excellent idea. I may fiddle with this if I can't get du to go.
</snip>
> > =========================
> > 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.
<snip>
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.
</snip>
> > 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.
<snip>
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.
</snip>
> > 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.
<snip>
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.
</snip>
--
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 -