Interesting thread (ls vs. ls -l) - lessons for newsgroups

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.

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 information.

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 itself.

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 also).

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 was.

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.

If you found something useful today, please consider a small donation.

Got something to add? Send me email.

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us