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

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

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER) (NEWEST)

Printer Friendly Version

Home

Blogging

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

Increase ad revenue 50-250% with Ezoic

Inexpensive and informative Apple related e-books:

Take Control of Pages

Take Control of iCloud

Take Control of Preview

Yosemite Crash Course

Take Control of Upgrading to Yosemite

Printer Friendly Version

Have you tried Searching this site?

Support Rates

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.

Printer Friendly Version