![](https://seccdn.libravatar.org/avatar/b12cfb65ca4faebc3e3aac17838e8f8d.jpg?s=120&d=mm&r=g)
Hi, The now-familiar find diagnostic "... changed during execution" has long been a source of mild curiosity to me. But with the recent brouhaha here, I decided to look into the actual issue at hand, so I installed the source for the 4.1.7 version of the "findutils" package (from my SuSE 9.1 Professional distribution). There are four places in the source code of find at which that diagnostic can be issued. In three of them, it is a change in either the device number of inode number of a directory being examined by find that triggers the (fatal) diagnostic. Two of those three pertain solely to the top-level directory (a find search root, either '.', the default, or one of the initial "path" arguments). With this in mind, the real cause of this diagnostic can be easily seen without the use of find at all: % cd /media # Print the device number and inode % stat -c '%d %i' dvd 14 1949 % stat -c '%d %i' dvd 14 1949 % ls -l dvd >/dev/null % stat -c '%d %i' dvd 5696 59392 % stat -c '%d %i' dvd 14 1949 My guess is that this behavior is a subfs / automounter issue. In fact, if I run "ls -l dvd" and follow it quickly by several invocations of "stat -c '%d %i'" I'll see the "5696 59392" numbers for a second or so and then it quickly reverts to "14 1949". % cd /media % alias sd='stat -c "%d %i" dvd' % alias ld='ls -l dvd >/dev/null' % sd; sd; sd; ld; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; 14 1949 14 1949 14 1949 5696 59392 5696 59392 5696 59392 14 1949 14 1949 14 1949 14 1949 So now we all know, right? Find is telling the truth. The mount-point directory does change both its device number and inode number when the removable media device that gets mounted there is automatically mounted and unmounted by the automounter. OK? Randall Schulz
![](https://seccdn.libravatar.org/avatar/6167b5e19c9699446f8122d902491a63.jpg?s=120&d=mm&r=g)
On Tuesday 04 January 2005 11:41 am, Randall R Schulz wrote:
Hi,
The now-familiar find diagnostic "... changed during execution" has long been a source of mild curiosity to me.
-->> snipped the EXCELLENT diagnosis <<--
So now we all know, right? Find is telling the truth. The mount-point directory does change both its device number and inode number when the removable media device that gets mounted there is automatically mounted and unmounted by the automounter.
OK?
Randall Schulz
Sweet! Now that was great diagnosis and troubleshooting to pin-point the problem. Thank you for clarifying the issue. The find command does not know how to traverse the subfs automount feature and it has not been updated to do this. Excellent answer. Thanks again for showing us what is happening with the 'progress' of my favorite Linux distro. Will you submit this through http://www.suse.de/cgi-bin/feedback.cgi or may I do it for you? I'd just cut&paste your email into the technical feedback report. THANKS! Stan
![](https://seccdn.libravatar.org/avatar/b12cfb65ca4faebc3e3aac17838e8f8d.jpg?s=120&d=mm&r=g)
Stan, On Wednesday 05 January 2005 06:59, Stan Glasoe wrote:
On Tuesday 04 January 2005 11:41 am, Randall R Schulz wrote:
Hi,
The now-familiar find diagnostic "... changed during execution" has long been a source of mild curiosity to me.
-->> snipped the EXCELLENT diagnosis <<--
So now we all know, right? Find is telling the truth. The mount-point directory does change both its device number and inode number when the removable media device that gets mounted there is automatically mounted and unmounted by the automounter.
OK?
Randall Schulz
Sweet! Now that was great diagnosis and troubleshooting to pin-point the problem. Thank you for clarifying the issue. The find command does not know how to traverse the subfs automount feature and it has not been updated to do this.
There are other cases where this happens, in my experience, though that experience is not with Linux, per se (it's with Cygwin--<http://cygwin.com/>). It may well have other Linux manifestations unrelated subfs / automounting.
Excellent answer. Thanks again for showing us what is happening with the 'progress' of my favorite Linux distro. Will you submit this through http://www.suse.de/cgi-bin/feedback.cgi or may I do it for you? I'd just cut&paste your email into the technical feedback report.
Thanks. I will not be able to do that today, so if you're anxious to see it done, feel free. Otherwise, I'll do it tomorrow morning.
THANKS! Stan
Randall Schulz
![](https://seccdn.libravatar.org/avatar/b12cfb65ca4faebc3e3aac17838e8f8d.jpg?s=120&d=mm&r=g)
Stan, On Wednesday 05 January 2005 06:59, Stan Glasoe wrote:
... Will you submit this through http://www.suse.de/cgi-bin/feedback.cgi or may I do it for you? I'd just cut&paste your email into the technical feedback report.
I've submitted a technical feedback report for this problem.
THANKS! Stan
Randall Schulz
![](https://seccdn.libravatar.org/avatar/99d6a2e78880aae0536e8653e5f8823c.jpg?s=120&d=mm&r=g)
Randall R Schulz wrote:
Hi,
The now-familiar find diagnostic "... changed during execution" has long been a source of mild curiosity to me.
But with the recent brouhaha here, I decided to look into the actual issue at hand, so I installed the source for the 4.1.7 version of the "findutils" package (from my SuSE 9.1 Professional distribution).
There are four places in the source code of find at which that diagnostic can be issued. In three of them, it is a change in either the device number of inode number of a directory being examined by find that triggers the (fatal) diagnostic. Two of those three pertain solely to the top-level directory (a find search root, either '.', the default, or one of the initial "path" arguments).
With this in mind, the real cause of this diagnostic can be easily seen without the use of find at all:
% cd /media
# Print the device number and inode % stat -c '%d %i' dvd 14 1949
% stat -c '%d %i' dvd 14 1949
% ls -l dvd >/dev/null
% stat -c '%d %i' dvd 5696 59392
% stat -c '%d %i' dvd 14 1949
My guess is that this behavior is a subfs / automounter issue. In fact, if I run "ls -l dvd" and follow it quickly by several invocations of "stat -c '%d %i'" I'll see the "5696 59392" numbers for a second or so and then it quickly reverts to "14 1949".
% cd /media % alias sd='stat -c "%d %i" dvd' % alias ld='ls -l dvd >/dev/null'
% sd; sd; sd; ld; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; sleep 1; sd; 14 1949 14 1949 14 1949 5696 59392 5696 59392 5696 59392 14 1949 14 1949 14 1949 14 1949
So now we all know, right? Find is telling the truth. The mount-point directory does change both its device number and inode number when the removable media device that gets mounted there is automatically mounted and unmounted by the automounter.
OK?
Randall Schulz
Great, that sounds good for the case wiith the ". changedduring execution of find" but this is only the weird thing we were looking on. Unfortunately it doesn't tell why I can NOT find with find some files even though they are definitely there AND I of cause gave --follow and was looking for even more options. During the past I could use find allways in the way I wanted it even in quite complex instructions, but this time it simply didn't work anymore. If nobody will find the cause for this bug I will do it, only I don't have the time for it right now. Martin
![](https://seccdn.libravatar.org/avatar/5a7166c7cfba16db9c3066d0f5eac66d.jpg?s=120&d=mm&r=g)
On Wed, Jan 05, 2005 at 04:30:07PM +0100, Martin Deppe wrote:
Great, that sounds good for the case wiith the ". changedduring execution of find" but this is only the weird thing we were looking on.
Unfortunately it doesn't tell why I can NOT find with find some files even though they are definitely there AND I of cause gave --follow and was looking for even more options.
It does tell. Find chokes on subfs before getting to the files you're looking for, plain simple.
During the past I could use find allways in the way I wanted it even in quite complex instructions, but this time it simply didn't work anymore.
Find does not work the way you expect it to because you have subfs mounted.
If nobody will find the cause for this bug I will do it, only I don't have the time for it right now.
The cause has been stated pretty clear, it's subfs. -Kastus
participants (4)
-
Kastus
-
Martin Deppe
-
Randall R Schulz
-
Stan Glasoe