James Knott wrote:

Martin Markgraf wrote:

...

Hi all,

I recently installed SuSE 9.2 on my laptop and it seems to me, that the "find" command is buggy.

On all older versions of SuSE and on all other linux distributions I know, a command like `find / -name "*ko"` will give me a list of all files in the system that end on "ko" (like /lib/modules/2.6.4-52-default/kernel/fs/quota_v2.ko )

But on SuSE 9.2 all I get is:

"find: . wurde waehrend der Ausfuehrung von find geaendert." (german error message that means something like "find: . was changed during execution of find" )

That exact command works fine here.

For me it doesn't work properly either. When I do a find on my homedir I get about 3000 files out of about 36000 which "ls -LR" finds. The only thing I did so far is to look into the man pages to figure out what I was doing wrong. Well this list issue tells me that there is more about it than what I was considering (simply not to know how to do it) because I have lots of symbolic links. But still, if I tell find to -follow then it should find all of them, shouldn't it? Anybody any idea about it now? cu Martin

Randall R Schulz wrote:

Martin,

On Monday 03 January 2005 14:30, Martin Markgraf wrote:

...

Hi all,

I recently installed SuSE 9.2 on my laptop and it seems to me, that the "find" command is buggy.

Untrue. Find is behaving as it is designed to.

No, it is not! At least not in MY environment!

...

On all older versions of SuSE and on all other linux distributions I know, a command like `find / -name "*ko"` will give me a list of all files in the system that end on "ko" (like /lib/modules/2.6.4-52-default/kernel/fs/quota_v2.ko )

Once you get your (related) updatedb problem fixed, I think you'll find "locate" to be a much better way to handle tasks like this. It will be far faster and spare your disk a lot of thrashing and keep important data in your RAM-resident buffer cache.

...

But on SuSE 9.2 all I get is:

"find: . wurde waehrend der Ausfuehrung von find geaendert." (german error message that means something like "find: . was changed during execution of find" )

No files shown.

This is a familiar problem to me. It happens even on Windows (under Cygwin). I have never taken the time to find the exact conditions under which find issues that diagnostic, but I know it happens in some directories and not in others.

For example, on my system:

% cd /media % ls -1F cdrom/ dvd/ dvdrecorder/ floppy/ usb-storage-D235281419110:0:0:0p1/

% find cdrom cdrom find: . changed during execution of find

% find dvd dvd find: dvd: No medium found

% find dvdrecorder/ dvdrecorder/ find: . changed during execution of find

% find floppy floppy find: floppy: No medium found

% find usb-storage-D235281419110\:0\:0\:0p1/ usb-storage-D235281419110:0:0:0p1/ find: . changed during execution of find

Precisely! I had this problem too (now as you wrote this I remember it again).

...

Someone on this list suggest to be more specific and try something like "find /lib..." but that can't be the solution, or I (and I guess a *lot* of other people) have to change a *lot* of scripts. Sometimes you have to search the whole filesystem.

Same problem with "updatedb". The command only returns "/usr/bin/find: . wurde waehrend des Ausfuehrens von /usr/bin/find geändert."

Steer updatedb around the directories that exhibit the symptom.

...

...

UPDATE: I found at this verry moment that the find error messages appears when find hits a filesystem of type "subfs" (like a automounted SuSE DVD ;) After removing the DVD "find" , "updatedb" and "locate" work as expected.

So those are the ones to exclude from updatedb's attention.

Do this by editing "/etc/sysconfig/locate".

For example, updatedb, and hence the "locate" command, works correctly on my system becaues "/media" (see above) is one of the excluded directories.

...

But again, I don't get this error message on SuSE 9.1 and I thing the behaviour of "find" in 9.2 should be fixed.

Find is not broken.

...

regards, martin

Randall Schulz

Martin Deppe

Doug, On Monday 03 January 2005 18:34, you wrote:

Hi,

Randall R Schulz wrote:

...

Martin,

On Monday 03 January 2005 14:30, Martin Markgraf wrote:

...

Hi all,

I recently installed SuSE 9.2 on my laptop and it seems to me, that the "find" command is buggy.

Untrue. Find is behaving as it is designed to.

Sorry, but it doesn't. Find is designed to find files and is does not under certain conditions. So I name it broken. Or perhaps better SuSE 9.2 should be named broken because the verry same command works fine on other systems.

You are wrong. Just because find, when run on your entire filesystem, produces output different than it did in the past in no way implies that it is broken. Find is not broken. You're using it in ways that produce that diagnostic. Period.

...

...

On all older versions of SuSE and on all other linux distributions I know, a command like `find / -name "*ko"` will give me a list of all files in the system that end on "ko" (like /lib/modules/2.6.4-52-default/kernel/fs/quota_v2.ko )

Once you get your (related) updatedb problem fixed, I think you'll find "locate" to be a much better way to handle tasks like this. It will be far faster and spare your disk a lot of thrashing and keep important data in your RAM-resident buffer cache.

If you only want so find a certain file, "locate" is your choice. But "find" can do far more things and a good sysadmin that have to deal with more than one operating systems relay on that a gnu find is the same under SuSE Linux, Solaris (with the GNU tools), HP-UX and *BSD, to name a few. I only gave a quiet simple example to show the problem.

Yes, find can do "far more things." At great expense, too. Your initial example was to find kernel modules. For that purpose and when files less than a day old are not an issue, "locate" is definitely the tool of choice.

...

So you see the problem but your way to deal with a problem is to ignore the problem. Sorry, but it doesn't sound right to me.

There is no problem. The mere fact that commands produce diagnostics is not a sign of a "problem." Find is reporting the diagnostic it did because the condition that triggers that diagnostic arose. If you assume that nothing is going to change when you upgrade your system, why perform the upgrade?

...

...

Someone on this list suggest to be more specific and try something like "find /lib..." but that can't be the solution, or I (and I guess a *lot* of other people) have to change a *lot* of scripts. Sometimes you have to search the whole filesystem.

Same problem with "updatedb". The command only returns "/usr/bin/find: . wurde waehrend des Ausfuehrens von /usr/bin/find geändert."

Steer updatedb around the directories that exhibit the symptom.

As stated before, to shut your eyes before a problem isn't my approach.

Jesus. It's not a problem. It's not a bug. It's find reporting what it found. Just get used to it, 'cause you're not going to get find to stop diagnosing the error it's diagnosing.

...

...

UPDATE: I found at this verry moment that the find error messages appears when find hits a filesystem of type "subfs" (like a automounted SuSE DVD ;) After removing the DVD "find" , "updatedb" and "locate" work as expected.

So those are the ones to exclude from updatedb's attention.

Do this by editing "/etc/sysconfig/locate".

Thanks, I know how to read man-pages.

Then what really is your complaint? Adapt to the situation at hand and be done with it.

...

For example, updatedb, and hence the "locate" command, works correctly on my system becaues "/media" (see above) is one of the excluded directories.

And what if I *want* to index /media ?

Removable media? What's the meaning of an once-per-day index of media than can be changed many, many times in that period? As far as running find directly on file systems that otherwise produce the ". changed ..." diagnostics, you can simply run find on all the individual files in the directory in question: % find cdrom |wc -l find: . changed during execution of find 1 % find cdrom/* |wc -l 4238 This technique will only break down when the content of the top-level directory exceeds the kernel argument size limits, which are pretty large under Linux.

...

...

But again, I don't get this error message on SuSE 9.1 and I thing the behaviour of "find" in 9.2 should be fixed.

Find is not broken.

See above, it is. Or SuSE 9.2 is, which way around doesn't mather for me.

I don't know what you're saying here, but find is _not_ broken. You're just going to have learn to deal with subfs file systems some other way.

regards, martin

Randall Schulz

On Monday 03 January 2005 9:48 pm, Randall R Schulz wrote:

...

And what if I *want* to index /media ?

Removable media? What's the meaning of an once-per-day index of media than can be changed many, many times in that period? yiiiiiikes! I'm trying to convince Kaffeine NOT to save old media, as in , I swapped out that dvd a week ago for crissakes! I don't need it to build a database of stuff it doesn't like for me. But , apparently I will also get used to it. WTF my computer has trained me better than yours has you apparently.

uh, note to all: that's a JOKE, okay? It seems that the biggest problem in this whole series is a major jump and huge changes to the os that occurred between 8.0 and 9.2.. there has been for some of us a pretty big jump just between 9.1 and 9.2. In case you guys haven't noticed, they aren't turning out this stuff for fun, there is a demand to have the OS operate in ways that are easy for Windows users to adapt to... or just not notice. Which is fine w/ me... This is our next big test.. getting it onto desktops all over the place, so they don't notice. After all even most Windows users don't give a monkey's bum about the OS they use. They want their email and web browsing w/ all the stupid singing and dancing the windows users have got used to wasting their time and bandwidth w/. Once over that hurdle, w/ required safety ( we require it and they also need it but aren't aware it can even be done at all.), we can go about changing their operating methods. Or would you prefer to stay as a 'niche' OS, not god enough for the desktop ?? I suspect there are quite a few Linux tech guys and programmer types who prefer the model we presently have. More business means more jobs.. period. Only reason I don't have two more users to my count, can't get a lappy to boot from a cd, so no install that way.. and that is going to mean taking custody of the thing so we can stick it in the network here and install that way for him. ( no floppy either in the new ones... or middling new anyway , weird that.) -- j nemo me impune lacessit 'Quis custodiet ipsos custodiates?'

Martin, On Monday 03 January 2005 20:46, Martin Markgraf wrote:

...

Yeah. On a single System stand alone. But I have to do it on a larger system consisting of different OS. And it worked before 9.2. Why upgrading ? Because I'm a fool and believing in the world become a better place ?

You say "it worked," but what you really mean is "it produced no diagnostic." It's still working, just working differently.

...

% find cdrom |wc -l find: . changed during execution of find. 1

% find cdrom/* |wc -l 4238

This technique will only break down when the content of the top-level directory exceeds the kernel argument size limits, which are pretty large under Linux.

The "find: . changed during execution of find." message doesn't indicate that it's a good ol' * command line size limit "bug", it is something different and it doesen't appaer before 9.2 on my systems.

What? I was offerring a work-around, not an explanation for the symptom.

...

...

...

...

But again, I don't get this error message on SuSE 9.1 and I thing the behaviour of "find" in 9.2 should be fixed.

Find is not broken.

See above, it is. Or SuSE 9.2 is, which way around doesn't mather for me.

Find is not broken. It's doing what it has done for many years under these circumstances. Just because you haven't seen it before, doesn't mean it's a new thing. And it certainly does not mean it's a bug. But if you're so damn sure this is something malfunctioning, file a bug report. You'll be waiting a very long time to get it "fixed."

...

I don't know what you're saying here, but find is _not_ broken. You're just going to have learn to deal with subfs file systems some other way.

Whatever. Systems with SuSE 9.1 gave result a) and systems with SuSE 9.2 gave result b). ...

Things change. You can adapt or complain. I can see which you've chosen. Stick with SuSE 9.1 forever, if that what makes you comfortable.

martin

Randall Schulz

Martin, On Tuesday 04 January 2005 03:01, Martin Deppe wrote:

Pals, I kind of get the idea that you must feel kind of silly!

I do not feel the least bit silly.

There IS a problem with "find" Martin has (obviously) since I (Martin too) have the same problem on my sytem (SuSE 9.2 too). I didn't notice it on up to 9.1, so it might well be that it doesn exist there.

If you're going to keep repeating this nonsense, I'll have to keep repeating the truth: There IS NOT a problem with "find".

As I wrote before I made a find in my home dir and as a result it got about 3,000 files/entries, but when I do the same with "ls -LR" it gets about 36,000 which isn't (referring to Adam Riese) the same AND I do not find (with find) files which are DEFINITELY there. As I stated before I prior to this list issue thought I made a mistake the way I was USING find, but not anymore.

Do you really mean "ls -LR" or is it "ls -lR"? Because I would expect a discrepancy with the former (w.r.t. find) because you've told ls to follow symbolic links which find does not do (unless you give the "-follow" option): % CD $HOME % ls -LR |wc -l 12831 % ls -lR |wc -l 1771 % ls -R |wc -l 1643 % find |wc -l 8282 % find -follow 2>/dev/null |wc -l 595157 Now please, stop pointing your finger at find. IT IS NOT BROKEN!

And NOW I would like to have the real WHY and on the other hand a SOLUTION for this problem.

The solution is to read the manual pages and understand the tools with which you are working.

...

Thanks for your understanding Martin

Randall Schulz

Glenn, On Wednesday 05 January 2005 03:51, Glenn Holmer wrote:

Randall R Schulz wrote:

...

% find cdrom |wc -l find: . changed during execution of find 1

% find cdrom/* |wc -l 4238

I think what's being asked here is *why* this happens now and didn't before. (Philipp asked for a use case, and I think you just gave him one.) Telling people to "just deal with it" is not helpful.

Well, he did not ask any questions. He claimed that something was broken just because he didn't like what it did. Dealing with it is the only option he has, really. I also offered work-arounds for "dealing with it."

This problem can be particularly vexing if you want to do a find from somewhere pretty high up in the filesystem (in which case -xdev seems to help).

Find is a very powerful tool, but it's also very expensive, especially as you describe, when searching from a point near the root of the file system. Doing so also often produces a large number of diagnostics owing to unreadable system directories.

-- Glenn Holmer

Randall Schulz

Martin Markgraf [Tue, 04 Jan 2005 03:34:05 +0100]:

Or perhaps better SuSE 9.2 should be named broken because the very same command works fine on other systems.

One command is failing for (yet) unknown reasons and you call the complete distribution broken ...

As stated before, to shut your eyes before a problem isn't my approach.

If you had known the reason you wouldn't have asked here. So why reject a usable workaround?

See above, it is.

Yes, seems like find has a bug, but a quick glance at the code doesn't reveal anything obvious. Do you have a reliable way to reproduce this? Possibly a way that *I* can reproduce? Then I could check to see if I find the reason.

Or SuSE 9.2 is, which way around doesn't mather for me.

Find possibly has a bug that triggers under certain conditions, that doesn't make it broken. As stated, present a reproducible test case and the chances the culprit can be locate get much better. Philipp -- Philipp Thomas SUSE LINUX Products GmbH

Martin, On Monday 03 January 2005 19:35, Martin Markgraf wrote:

...

No, you are right. it doesn't. I just was angry about all the "there is no problem" voices.

Nonetheless, there is no problem. Just your failure to acknowledge reality. Find does what it does. If you can't deal with that, don't use it.

...

Martin Markgraf

Randall Schulz

I have a newbie question and I'm new to the list so excuse if this question has been posted before. I installed SuSE 9.2 on a HP Pavilion AMD64 laptop. I'm using this at work where I need to log into other (solaris) machines and run X applications (such as emacs and other inhouse apps). On one particular machine I can run these apps but on most other machines I get the following error message: XView warning: Cannot load font set '-b&h-lucida-medium-r-normal-sans-*-120-*-*-*-*-*-*' (Font package) XView warning: Unable to open default font set XView error: Cannot open connection to window server: 137.236.224.187:0 (Server package) The steps I take are: %xhost remote_machine %ssh -X -l user remote_machine %setenv DISPLAY myip:0 I had to remove the "-nolisten tcp" argument from the startx script. Anyway, am I missing a particular font set? If yes, where can I get the required font set? If no, what am I doing wrong? Thanks in advance, Mark

Joe, On Tuesday 04 January 2005 06:45, Joe Polk wrote:

---------- Original Message ----------- From: Randall R Schulz

...

Nonetheless, there is no problem. Just your failure to acknowledge reality. Find does what it does. If you can't deal with that, don't use it.

...

Martin Markgraf

Randall Schulz

Okay, that is absolutely stupid. He clearly outlined a problem.

A problem that exists entirely within his (lack of) understanding of the software he's using.

Let me paint a picture that you seem to have a problem seeing. If you run a find command exactly the same on every other distro and it works, but doesn't in SuSE 9.2, guess what, Skippy, IT'S BROKE! THERE'S A PROBLEM!

I'm sorry, but this is faulty logic. It would be valid only if the only thing that changed between the two distributions was find itself. Do you believe that's true?

I'm really tired of people setting up 9.2 or any other distro as some sort of Holy Grail.

This is baseless and irrelevant. I'm running 9.1 and I can see the symptom. As I said in my first reply on this topic, it happens with Gnu find running under Cygwin on Windows.

It has problems.

It is working correctly.

Maybe not for everyone, but it does for some.

It exhibits different behaviors on different systems because the systems are different, not because it is broken on some systems.

For what it's worth, I've seen this same behavior. Commands that I routinely run with find failing with that same exact syntax. Guess what? They worked on 9.0. Furthermore, it's nice that a work around was offered; hat's off! Yet, that doesn't negate the basic problem: find has a bug or some other issue.

Find does not have a bug. At least not regarding this behavior.

The point of bringing it up here isn't to shoot your sacred cow.

I have no sacred cows, but I cannot allow false information and faulty logic to enter the SuSE-Linux-E archive unchallenged.

It's to draw attention to it and have someone, someone MATURE, take notice. Grow up!

I don't need to be told to "grow up" by you. I'm the only one here explaining real facts and using valid logic.

It's just a distro and it's far from perfect. This guy could walk into an ER with you folks with a gunshot wound and you'd say, "Well, I don't have a gunshot wound."

I have no devotion to, feelings about or sense of obligation to defend any software, operating system or distribution. I do, however, feel some duty to defend facts and logic against the onslaught of nonsense.

-- <<JAV>>

Randall Schulz

Martin, On Tuesday 04 January 2005 12:38, Martin Deppe wrote:

Randall,

guess what! You poor o' guy, don't bother me/us anymore and shut up, will you?

So, you're admitting you're wrong? Good.

Cheers

You say "cheers" when you're telling me to "shut up?" You're a hypocrite.

Martin P.S. well the other chance is to put a filter on all mails coming from you!!!!!!

Please do. Clearly, facts don't serve you and you need to be protected from reality, and I'm never going play along with that sort of mentality. Randall Schulz

Kolja, On Tuesday 04 January 2005 16:44, Kolja Kauder wrote:

Randall,

Randall R Schulz wrote: ...

I feel I have to second Joe's opinion. If the answer to find /media/cdrom "something" is ". has changed during ....." that sounds like a fault (or at least faulty diagnostics) to me unless you mount a writable media there. The locate-solution wouldn't work for me since most of my important files that I care to find are mounted via nfs.

You and Joe are entitled to your opinions, but this diagnostic is simply find telling the user what happened, not a bug.

I can't really comment on the "ls -lR"-issue but there could be a problem with links. OOffice for example creates a link to my home directory _in_ my home directory resulting in much recursive pain when using find.

It's not a "problem," just the fact that symbolic links are treated differently by both "ls" and "find" and each has respective options that alter that variant treatment. The discrepancy reported by an earlier writer (Martin?) was a result of using find and ls in ways that cause them to visit different amounts of the file system.

...

...

Let me paint a picture that you seem to have a problem seeing. If you run a find command exactly the same on every other distro and it works, but doesn't in SuSE 9.2, guess what, Skippy, IT'S BROKE! THERE'S A PROBLEM!

I'm sorry, but this is faulty logic. It would be valid only if the only thing that changed between the two distributions was find itself. Do you believe that's true?

Well, you put it a little to simply. Adherence to some basic command-behavior can and should be expected. I guess you'd agree if the behavior of "test" was changed. And I find your logic faulty. If it works here and crashes there, who cares what else was changed? He doesn't blame the distro, he rightly blames the command.

Joe made an implicit premise of his argument the fact that only find changed, since that's where he saw a change in observable behavior. But it is not find that changed. It was other characteristics of the file system to which it was applied.

...

...

I'm really tired of people setting up 9.2 or any other distro as some sort of Holy Grail.

This is baseless and irrelevant. I'm running 9.1 and I can see the symptom. As I said in my first reply on this topic, it happens with Gnu find running under Cygwin on Windows.

So maybe it's a known bug. Doesn't make it right.

It is not a bug of any sort, known or unknown. It is find doing what it has done for a very long time under the circumstances it detected. See "The Trouble With Find" for some technical details.

...

...

It has problems.

It is working correctly.

Is it? It seems to have some strange problems with subfs. The problem-that-is-none you observed on cygwin may be related to something different.

Yes. Subfs / automounter elicits a diagnostic. It does this in 9.1 as well as 9.2. It is not a bug in find.

...

...

Maybe not for everyone, but it does for some.

It exhibits different behaviors on different systems because the systems are different, not because it is broken on some systems.

Including the possibility that it shows _bugs_ only on some systems.

A priori, that possibility must be considered, but the facts at hand don't support it.

...

...

For what it's worth, I've seen this same behavior. Commands that I routinely run with find failing with that same exact syntax. Guess what? They worked on 9.0. Furthermore, it's nice that a work around was offered; hat's off! Yet, that doesn't negate the basic problem: find has a bug or some other issue.

Find does not have a bug. At least not regarding this behavior.

see above.

See above and the message "The Trouble With Find."

...

...

The point of bringing it up here isn't to shoot your sacred cow.

I have no sacred cows, but I cannot allow false information and faulty logic to enter the SuSE-Linux-E archive unchallenged.

...

It's to draw attention to it and have someone, someone MATURE, take notice. Grow up!

I don't need to be told to "grow up" by you. I'm the only one here explaining real facts and using valid logic.

Well, Joe's statement isn't exactly mature but your insisting that a real problem of his simply is nonexistent doesn't help...

I know what's really happening. You're mired in a "I did this before and when I do it now the result is different, ergo there's a bug" mode of thought. You need to reevaluate the facts and adapt, 'cause find will not be changing to assuage your problem. But you could always modify find locally to have it ignore the condition it's diagnosing.

<snip emerging flames>

So far, there has been no flaming here. Are you preparing to start?

...

...

-- <<JAV>>

Randall Schulz

Aaah, while writing this, it begins to dawn on me: automount mounts and changes /media/cdrom to search in it. So Randall is right, it is not, strictly speaking, a bug. Nevertheless, it seems not to happen on prior versions. And it is not "intelligent" behavior, doesn't happen with nfs-mounts for example. Best workaround seems to be to change cdrom etc. to the "old" behaviour.

But it does happen in earlier versions than 9.2. It happens for me in 9.1. It happens for me, and has for years, under Cygwin on Windows. Most likely, the people experiencing a change in behavior are using subfs / automounter for the first time. At least they are bringing find and subfs together for the first time. I'm not in a position to empirically assess how Samba / CIFS or NFS shares interact with this aspect of find, since I'm on an isolated home computer and do not use either of these file sharing mechanisms.

The behavior is consistent, though, and I wonder why it didn't happen earlier.

But it did.

This said, you are right. This doesn't touch my criticism since you only said "find did it for many years" which is 1) not helpful, 2) no argument at all, and 3) not true, this special incarnation is an artifact of the subfs-mechanism.

My empirical facts are just as good as yours. Find has issued this diagnostic under the appropriate conditions for a long time.

No offence meant, I've read many helpful and patient mails from you, just felt you were a little unjust here.

I'm not offended, but I'm not going to back down as long as I know I'm right, and in this matter, I am right.

A happy new year to all of you! Kolja

Randall Schulz

Joe, On Tuesday 04 January 2005 17:35, Joe Polk wrote:

Okay, then perhaps there is a bug in SuSE 9.2 causing find to output this string. I may, MAY, have misstated then. Doesn't matter, there's a bug somewhere. I've seen this behavior on the exact same system installed with SuSE 9.2 that I ran 9.0 on. BUt I'll give you that, it might not be find. It may be that find is giving a symptom of another problem within 9.2.

There is no bug afoot here. See my post "The Trouble With Find" for an explanation of what's happening.

-- <<JAV>>

Randall Schulz