Why can't Find File STOP when asked?

[John Bowling]

I am REALLY PISSED at it. Multiple hits on every control button does
NOTHING!

It goes off in the wild and the only recovery is a POWER reset, and it
want's to resume as soon as it comes up again. It's a MAJOR example of
CRAP!!!

I was using 12.2 openSUSE with KDE3. 12.4 with KDE4 did NOT improve this.

Yet tree > grep -i "filetofind" has no problem, and returns in a few
seconds.

What a Major piece of CRAP find file is.

It's time to return it to the TRASH where it's lunacy escaped from and
all sub files.

John

[Paul J Gans]

houghi <hou...@houghi.org.invalid> wrote:

>Could you please leave out any specifics about what works? You did
>already a great job not telling us what does not work. This way it I am
>not able to fully test my, you know.

I gather that he was using the search function to try to find
a file. He then wanted to abort that search and found that he
could not do that.

One also gathers that the search function turns off signals.
Why? I do not know.

--
--- Paul J. Gans

[Sioux C. Queue]

On 05/01/2013 11:19 AM, Paul J Gans wrote:

> One also gathers that the search function turns off signals.
> Why? I do not know.

Have a "Konsole" running, as me the schmuck user, find / somefilename (this is
the wrong syntax but boy will it find lots of stuff). Ctrl-C breaks and stops
it almost instantaneously. A Ctrl-Z will "stop" it, necessitating a kill %1.
Maybe something with his terminal program, diddling with something right now
that doesn't capture a Ctrl-Alt-Del to do a reboot.

12.3 patched, etc.

[Darklight]

What file browser are you using to do the find/search.
What do you expect from a beta i am assumming that opensuse 12.4 is a beta?

[Norman Hull]

John, before lashing out and making yourself look silly, THINK and report
carefully what you did/were trying to do.

Just as Sioux C, Queue did, I tried a command line find.

find / -iname sfa >/dev/null
Goes off exploring my filesystems
^C and it ends - instantly.

If you were working in a window, did you ensure that it had the focus when
trying to kill the process?

If you were running some kind of GUI find and it wouldn't let you kill it
any other way - (note this is a GUI problem NOT a find problem)try Ctrl-Alt-
Escape. Turns your cursor into a skull and crossbones. click on a window
to kill it instantly.

BTW find is a great piece of software and - unlike the original SysV find it
defaults to printing the result. In Sysv find if you missed off the -print
find would locate your file(s) but wouldn't tell you where they were!
Confused the crap outa me!

Please also discard your Windows indoctrination. Under Linux it s seldom,
if ever, that a problem needs a reboot to resolve it.

--
Norman
If at first you don't succeed - give someone else a go

[Wade Jenkins]

Norman Hull wrote:


> Please also discard your Windows indoctrination. Under Linux it s
> seldom,
> if ever, that a problem needs a reboot to resolve it.

Not quite, you force kill an application, you think is over but is still
running in background waiting for free resources in a queue.

You cant proper kill a thread since it has shared data structures.

[Vic Titious]

Can I suggest Catfish?
It's a nice front-end to work with locate, tracker, etc.

[Norman Hull]

I bow to your superior knowledge.

To clarify, working with Linux since 1993 and before that unix since 1986 I
have yet to encounter a program problem that required a reboot. I *have*
seen an individual terminal become unusable and locked up on SysV unix,
though

[unruh]

Well, I have. -- stale nfs handles which did not respond to any of the
standard prcedures to get rid of them.
Another case is if your diskpartition has filled up, you tried to erase
a file, which happens to still be kept open by some program, but you
have no idea which program. the file is gone, the inode is unknown. How
do you free the space so your system can continue to operate?

But anyway, I doubt that he has run into and example. So if that thread
is causing problems, kill the parent as well.

Use kill -9 if necessary.

[Jeff Bennett]

unruh wrote:

> Well, I have. -- stale nfs handles which did not respond to any of the
> standard prcedures to get rid of them.
> Another case is if your diskpartition has filled up, you tried to erase
> a file, which happens to still be kept open by some program, but you
> have no idea which program. the file is gone, the inode is unknown. How
> do you free the space so your system can continue to operate?
>
> But anyway, I doubt that he has run into and example. So if that thread
> is causing problems, kill the parent as well.
>
> Use kill -9 if necessary.

Sure you does. Linux gets in fuck-mode many times, for various reason.

But you two still don't get it. Threads are sharing their data structures
by construction. Killing the parent would not help since whatever other
started thread is waiting at semaphore to write/read from a share resource.

[unruh]

That is called a parent-- the thing that started the thread and the
thing that shares the data structure with the thread ( if they do share
since fork does not share the structures). Besides the thread is a
separate process. If the other thread is waiting for a semaphore, it can
keep waiting. So what?
Anyway, what evidence do you have that this is the problem being
discussed?

[Jeff Bennett]

:)

> Anyway, what evidence do you have that this is the problem being
> discussed?

You must be stupid I guess.

[Aragorn]

On Monday 13 May 2013 17:51, Jeff Bennett conveyed the following to
alt.os.linux.suse...

> unruh wrote:
>
>> Anyway, what evidence do you have that this is the problem being
>> discussed?
>
> You must be stupid I guess.

Bill can be a bit terse in his replies at times, but you might want to
reconsider calling him stupid.

http://en.wikipedia.org/wiki/William_Unruh

Furthermore, he is absolutely correct, and _you_ instead appear to be
the one who doesn't "get" it.

--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net

[Jeff Bennett]

Aragorn wrote:

> Bill can be a bit terse in his replies at times, but you might want to
> reconsider calling him stupid.
>
> http://en.wikipedia.org/wiki/William_Unruh
>
> Furthermore, he is absolutely correct, and _you_ instead appear to be
> the one who doesn't "get" it.

No Sir, he must he told that a thread is a separate process, which is
exactly stupid, since this is what distinguish a thread from a process.

> since fork does not share the structures). Besides the thread is a
> separate process. If the other thread is waiting for a semaphore, it can

As said, a thread share its data region with other thread. Processes use
their own region, that transfer the eventually need data to other
processing using Message Passing.

Please apologise for your both confusion.

[Aragorn]

On Monday 13 May 2013 20:40, Jeff Bennett conveyed the following to
alt.os.linux.suse...

> Aragorn wrote:
>
>> Bill can be a bit terse in his replies at times, but you might want
>> to reconsider calling him stupid.
>>
>> http://en.wikipedia.org/wiki/William_Unruh
>>
>> Furthermore, he is absolutely correct, and _you_ instead appear to be
>> the one who doesn't "get" it.
>
> No Sir, he must he told that a thread is a separate process, which is
> exactly stupid, since this is what distinguish a thread from a
> process.

Both Linux (i.e. the kernel) and the GNU userland use the _POSIX thread
model_ and POSIX threads _appear in the list_ as if they were separate
processes with a shared context.

>> since fork does not share the structures). Besides the thread is a
>> separate process. If the other thread is waiting for a semaphore, it
>> can
>
> As said, a thread share its data region with other thread. Processes
> use their own region, that transfer the eventually need data to other
> processing using Message Passing.
>
> Please apologise for your both confusion.

No, but I will accept your apology - and I'm sure Bill will too - once
you've properly documented yourself on the difference between regular
threads and POSIX threads.

https://computing.llnl.gov/tutorials/pthreads/

[Jeff Bennett]

Aragorn wrote:

> Both Linux (i.e. the kernel) and the GNU userland use the _POSIX thread
> model_ and POSIX threads _appear in the list_ as if they were separate
> processes with a shared context.
>
>>> since fork does not share the structures). Besides the thread is a
>>> separate process. If the other thread is waiting for a semaphore, it
>>> can
>>
>> As said, a thread share its data region with other thread. Processes
>> use their own region, that transfer the eventually need data to other
>> processing using Message Passing.
>>
>> Please apologise for your both confusion.
>
> No, but I will accept your apology - and I'm sure Bill will too - once
> you've properly documented yourself on the difference between regular
> threads and POSIX threads.
>
> https://computing.llnl.gov/tutorials/pthreads/

"separate processes with a shared context" of data means threads not
processes. Huge difference. Pleas review your attitude. I expect you two
to apologise, which will be accepted.

[Peter Köhlmann]

You seem to have not enough smarts to understand the differences between a
"thread the windows way" and a "POSIX thread".
You even got some info handed already, and you failed completely
understanding that

[Jeff Bennett]

Peter Köhlmann wrote:

>> "separate processes with a shared context" of data means threads not
>> processes. Huge difference. Pleas review your attitude. I expect you
>> two to apologise, which will be accepted.
>
> You seem to have not enough smarts to understand the differences between
> a "thread the windows way" and a "POSIX thread".
> You even got some info handed already, and you failed completely
> understanding that

I think I would apologise to you people, you being three or more, I being
alone.

I was wrong telling that

- a thread starts and run by sharing its data address space with other
running threads.

- a process starts and does not share its data address space with
other processes or threads.


Both of these statements are wrong according with you three (or four). I
do apologise, and I hope will be accepted.

[unruh]

On 2013-05-13, Jeff Bennett <jbe...@gmail.com> wrote:

> Peter K??hlmann wrote:
>
>>> "separate processes with a shared context" of data means threads not
>>> processes. Huge difference. Pleas review your attitude. I expect you
>>> two to apologise, which will be accepted.
>>
>> You seem to have not enough smarts to understand the differences between
>> a "thread the windows way" and a "POSIX thread".
>> You even got some info handed already, and you failed completely
>> understanding that
>
> I think I would apologise to you people, you being three or more, I being
> alone.
>
> I was wrong telling that
>
> - a thread starts and run by sharing its data address space with other
> running threads.

It can, or it cannot. man fork, man clone.

>
> - a process starts and does not share its data address space with
> other processes or threads.

It can or it cannot. A process often is a fork from a shell say, and
then has its own memory space.

But it will have a parent, the process that forked/cloned it.

[Jeff Bennett]

unruh wrote:

>> running threads.
>
> It can, or it cannot. man fork, man clone.
>

...

>
> But it will have a parent, the process that forked/cloned it.
>

Has nothing to do with fork. But I suppose I am wrong. I must be since you
people are so many. Cheers.

[unruh]

On 2013-05-13, Jeff Bennett <jbe...@gmail.com> wrote:

man clone
The main use of clone() is to implement threads: multiple threads of
control in a program that run concurrently in a shared memory
space.


man fork

A call to fork() is
equivalent to a call to clone(2) specifying flags as just
SIGCHLD.

Ie, clone is the overlying call, and clone creates both threads and
fork.
i

[Aragorn]

On Monday 13 May 2013 21:29, Jeff Bennett conveyed the following to
alt.os.linux.suse...

Yes, you are correct. They are threads, not processes. Unfortunately
for your peace of mind, POSIX threads are made to _appear_ as processes
in a process listing.

> Pleas review your attitude. I expect you two to apologise, which will
> be accepted.

I do not intend to apologize for being right, and especially not to
someone so bound on flaunting his ego that he demands an apology over
something as silly as this, especially so when he's wrong.

[Jeff Bennett]

Aragorn wrote:

>> "separate processes with a shared context" of data means threads not
>> processes. Huge difference.
>
> Yes, you are correct. They are threads, not processes. Unfortunately
> for your peace of mind, POSIX threads are made to _appear_ as processes
> in a process listing.

So tell it, he did a mistakes. The listing algorithm does not matter. One
must be aware that the return of a listing contains thread and processes.
You loose all the time.