Interesting thread (ls vs. ls -l) - lessons for newsgroups Thu Dec 23 12:50:37 2004
Referencing: Hangs doing ls -l but not ls
This thread is interesting because it shows how not
understanding underlying facts can lead to confusion. What the
poster had was a mounted cdrom and his observation was that an "ls
/dev" worked fine, but "ls -l" hung. He also observed that
different mount options caused varying behavior. The whole thing
turned out to be bad configuration (slave vs. master), but it is
the problem solving that interested me.
There are a lot of bad guesses and poor troubleshooting
techniques to be seen in the thread. For example, the first
response correctly noted that "ls -l" needs to access passwd and
shadow, and suggested that the problem might be there. He may have
thought that the original poster said ALL "ls -l" commands failed.
You certainly could read the original post and get that impression,
which was the first defect of the post: badly presented
Newgroups are an interactive medium, so minor omissions do
usually get straightened out. However, it's a point worth
remembering when you go forth to post: an erroneous impression
first gained may take tremendous effort to straighten out, and can
sometimes destroy the thread entirely, I had that happen to me
recently with a thread concerning getting an Iomega REV working on
. I was misunderstood, and had to abandon the thread
because I could not undo the original incorrect impression of what
was being asked.
But, it wasn't all listings, just the /dev and the mount point
of the CD, so the passwd/shadow idea couldn't be right. Next, a
suggestion was made to try "ls -bl". That poster must have been
thinking that control characters in file names were freezing screen
output. That would make no sense for several reasons: "ls" shows
the file names, and he had no problem with "ls". Secondly, the
problem in /dev exhibited only when the cd was mounted - mounting a
cd doesn't insert control characters in /dev file names. Finally,
trying a different cd would have fixed any oddity of the cd
Next came a suggestion pretty close to the truth that talked
about links to a failing mounted file system. This was really on
the mark, though the suggestion to "check to make sure you do not
have any links" was right out of left field. The links weren't the
problem, the hardware was. I think this respondent was looking at
the problem as "I don't know why THIS directory won't list" rather
than the actual problem. In other words, he apparently was thinking
of a case where you don't realize that there is a problem with a
mounted device and have forgotten that a link in a directory points
to that device. This poster didn't have that, he knew he was having
specific problems with a cd. But - although the "links" advice
probably caused misdirection, this answer actually was correct.
After some further attempts to blame this on passwd/shadow and
hidden characters, the thread moved to looking for "oddball"
entries in /dev. Obviously forgotten was that without mounting the
cd, there was no problem listing /dev. Again, I think this goes
back to the original post not well detailing the actual
observations. The passwd and odd files idea got kicked around some
more until the poster finally said
The hang is only happen on / and /dev. /dev/rmt is ok, as are all
other directories I've tried.....
(note that he mounted /dev/cd0 on /mnt, which is why / hangs
But the obvious was still being missed as he was next advised to
do "authck -av" - again, that misses that he had no problem with
the cd not mounted.
Finally, Bela Lubkin stepped in and made sense of it. Plainly the problem had to
be in the inode tables for the cd device - ls only has to read
directory entries of / and /dev, but ls -l has to go into the inode
for reach reference, and that is where it hung. No other
explanation fits the observed facts - though again, in fairness to
the other responders, the original poster did not present the
situation as well as he might have.
There are lessons to be learned for posters and responders.
Posters need to present observations accurately and thoroughly. As
I have suggested many a time:
- What were you trying to accomplish
- What you actually did
- What you expected to happen
- What conditions were present/not present
- What actually happened
In this case, the conditions were the critical point: the
problem was seen only when a cd was mounted. For the responders,
careful reading is what is often missed, but I think the more
important skill would be to avoid jumping into solving an
ill-stated problem and instead ask more questions to get a better
presentation. In this case, the first response might have been:
Why do you say everything "seems fine" if you
can't even do an "ls -l"?
That would have immediately initiated the explanation that the
problem was only when a cd was mounted. As that's still ambiguous,
we might then ask "Any cd or just a particular cd?" and "ls -l of
any directory or just specific directories?". Those two answers
would have given a more clear picture and I expect most of the
responders would have immediately seen where the real problem
Too often, we assume too much into what we read and what we
write. We are all guilty of it - I've done this as often as anyone.
That doesn't mean we can't try to do better in the future.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2011-06-20 Tony Lawrence