pFind 6.3

Filemanagers, partitioning tools, etc.
Post Reply
Message
Author
User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#101 Post by zigbert »

It could absolutely be a bug from 2.5. I messed with the code when refined the gui-handling. Can you try to run Pfind from terminal.

When opening files in texteditor, Pfind opens symlinks, and not the real files. Lets change this for version 2.6. In Grafpup you are running multiuser. Do this give trouble with permissions in /tmp/?

If trying to open MANY files in Geany I got an extreme delay.
once before I've had a search for "mp3" turn up 900 hits or something, but only a hundred and fifty or so showed up in the list, and the last entry was "/mnt/hdb6/", which has no "mp3", so something must have messed it up somehow.
I just wonder: Could it be problem with filenames not compatible with UTF-8 charset. Max hits in Pfind 2.5 is set to 500. I guess you edited the config file. If running a low-powered system it's not recomended. The option ACCEPT_ARROW is because I experienced that < and > gave trouble when handling filenames from iso8859.1.


Sigmund

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#102 Post by disciple »

No, it's not a permissions problem - multiuser is new in Grafpup 2. Grafpup 104 is basically Puppy 1.04 with some stuff changed. And I've got the same problems in Puppy 2.16 anyway.

I don't think it's just a delay, as I tried with a list of mp3's, and it built the links but nothing ever happened. Then I ran the command from the config file and xmms opened up with all the files quite quickly.

Yes I did edit the limit - I have a 900MHz Celeron, and it is slow, but not too slow. I really don't want to have the limit at less than 1000. But those list menu items aren't working for me with less than 200 hits.

Some of my test searches were just in my Windows 98 FAT32 partitions, as I thought it unlikely there'd be illegal characters or anything there - but I'm not sure. You can't use < and > on them anyway.

-----------------------------------
EDIT - Skip to the next post - I tested more thoroughly
-----------------------------------

I just tried it again, and it didn't say anything unusual in the terminal until I clicked the (gtkdialog - not WM) close button, when it closed pfind and spat out a list of all the files, like this:

Code: Select all

/usr/local/pfind/pfind: line 812: /mnt/hdb6/Upstairs/Songs/Kim: No such file or directory
for files with a space in the name, like there's some quotation marks missing somewhere, and like this:

Code: Select all

/usr/local/pfind/pfind: line 830: /mnt/hdb6/Upstairs/Messer011.mp3: cannot execute binary file
for files without spaces in the name - well of course it can't execute the file - it's an mp3 :)
and then this at the very end:

Code: Select all

/usr/local/pfind/pfind: eval: line 875: syntax error near unexpected token `('
/usr/local/pfind/pfind: eval: line 875: `/mnt/hdb6/04 The Package/12 Not To Win (The Fast).mp3'
With the other messages it was progressing one line at a time, but it jumped from line 862 to line 875.
Then it opened up the pfind results window again, with the results still there, and when I clicked close again it just closed normally.
The only thing I did after searching and before clicking the close button was click on List-open files in music player.
Last edited by disciple on Sat 06 Oct 2007, 22:38, edited 1 time in total.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#103 Post by disciple »

OK - that wasn't quite right. If I run a search for mp3 in hdb6 (a fat32 partition) this is what consistently happens:
First I get 274 hits. Then:
-If I just press close it closes normally.
-If I click List-Open musicplayer then it builds the symlinks, and then when I click close it closes and the terminal spits out the messages attached.
-If I click the button to show only sound files, it removes 5 files from the list. Then if I click List-Open musicplayer it builds the symlinks, and then when I click close it closes and the terminal spits out the other messages attached, and then pfind opens again, building a hitlist, and then brings up the search results window with all the same results. If I then click close it closes normally.

In neither case does it actually open the music player

Note that the two sets of messages are different (especially the last two lines), and that neither has a line for all of the files.

The lines that look like this

Code: Select all

/usr/local/pfind/pfind: line 862: /mnt/hdb6/01: No such file or directory
are for files with spaces in the name, the lines that look like this:

Code: Select all

/usr/local/pfind/pfind: line 840: /mnt/hdb6/Upstairs/Messer021.mp3: cannot execute binary file
are for files without spaces in the name, and the lines that look like

Code: Select all

/usr/local/pfind/pfind: line 877: CeCe: command not found
are the first part of a filename after an & and before the next space.
Those last two lines in one set of messages are probably for the only file with ( and ) in the name.
Attachments
JustClickingList-OpenWithMusicPlayer.gz
(1.28 KiB) Downloaded 527 times
afterClickingShowSoundFiles.gz
(1.05 KiB) Downloaded 509 times

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#104 Post by disciple »

actually it might not be exactly the last two lines in those files - I think I left the standard exit lines in one of them.

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#105 Post by zigbert »

OK, let's start tracking.

Your attacthed files tells that pfind start failing at line 655. This tells us that the misbehavour happens inside gtkdialog-code. It seems to me that that your filenames in hitlist corrupts the code. I guess this happens when building items for the hitlist. This because pfind includes /tmp/pfind-treeitems$PROGPID into the code.

What we need to look at are your file /tmp/pfind-treeitems$PROGPID just after showing the searchresult in the overview. If we could compare this list with the list 'find' gives us, I hope we could see what goes wrong. You of course know that 'find' executable is build in /tmp/pfind-execfind$PROGPID, but be aware of; if searching with several searchpaths 'find' will execute several times and /tmp/pfind-execfind$PROGPID shows only the last 'find'-command. Be sure that there are only one searchpath. Then the lists from pfind and find are comparable.

Sigmund

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#106 Post by disciple »

Hi, sorry - I've got to go to bed, so I can't really read closely and try to figure out how to get an output from the command line in the same format as the pfind-treeitems... file - also, it is in a different order - I guess pfind is sorting it in some way.

As you can see, it finishes like this:

Code: Select all

/mnt/hdb6/Upstairs/11-3-06.mp3|44142051|1998/01/01 - 14:48:44|-rwxr-xr-x|root
/mnt/hdb6/Upstairs/Messer001.mp3|182194387|2007/04/08 - 07:06:34|-rwxr-xr-x|root
/mnt/hdb6/Upstairs/Messer002.mp3|108292516|2007/03/04 - 06:59:02|-
If I remove the mp3 from the name of that last file, it has exactly the same results, finishing with the next file:

Code: Select all

/mnt/hdb6/Upstairs/Messer003.mp3|155037071|2007/04/15 - 07:05:04|-
There doesn't seem to be anything unusual about these files except they are big, and that can't be causing the problem as I had the same issue with a search for text files. I have no idea what else to look at, so if you have any suggestions...

NB. Also, after it builds the symlinks, the pfind-treeitems... file is correct - but it sounds like you might be expecting that.
--------------------------
Wait a minute - I just tested with a search for txt on my Linux ext3 partition - it came up with 59 hits, and the pfind-treeitems... file was complete, but it has the same behaviour - builds hits, but never opens the text editor. But wait - it doesn't do the thing of reopening pfind when closed if I'd clicked a button to display only some of the results. So maybe there are two separate issues here.
Attachments
txt1.gz
(1.87 KiB) Downloaded 575 times
pfind-treeitems1267.gz
(5.05 KiB) Downloaded 559 times
find.gz
(3.36 KiB) Downloaded 558 times

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#107 Post by zigbert »

This was a tricky one, but let's not give up yet.

Can you please give me:
1. /tmp/pfind-files - This file shows the result of 'find'
2. /tmp/pfind-view - This is the files to be in the overview list.
3. /tmp/pfind-treeitems - This is the syntax for gtkdialog tree-view.
4. result of find /mnt/hdb6 -iname *mp3*
5. result of find /mnt/hdb6 -iname *mp3* -printf "%p|%s|%CY/%Cm/%Cd - %CT|%M|%u\n"

Nr. 4 should be equal to pfind-files and pfind-view. Nr. 5 should be equal to pfind-treeitems.

I wonder if anyone else got an experience close to this. If you read this, please give your report.

Sigmund

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#108 Post by disciple »

OK - I'm off to uni now :)
Attachments
results.tar.gz
(22.16 KiB) Downloaded 474 times

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#109 Post by zigbert »

Ok, now we know that Pfind search correct, but fails in the func 'build_treeitems'. The main code here are this:

Code: Select all

#!/bin/bash
echo -e "\c" > /tmp/pfind-treeitems
for I in `cat /tmp/pfind-view | sed -e "s/ /{ð®Sđþ}/g"`; do
	TMP=`echo "$I" | sed -e "s/{ð®Sđþ}/ /g"`
	find "$TMP" -maxdepth 0 -printf "%p|%s|%CY/%Cm/%Cd - %CT|%M|%u\n" >> /tmp/pfind-treeitems
done
If you could:
1. Make the search.
2. Rename '/tmp/pfind-view$PROGPID' to '/tmp/pfind-view'.
3. Run this code.
4. check '/tmp/pfind-treeitems'

.....If everything is now ok.....Wow, I have no idea??????

.....If still the same failure..... Please try to tweak the code to see if you can pass the failure. The {ð®Sđþ} is just instead of ' ' (space) to get the for-loop to run filenames with spaces. Maybe find -printf "%...." needs a refreshment.

I'm curious :wink:

Sigmund

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#110 Post by disciple »

That works (I mean the contents of that file are correct) - which means you have no idea about why that file is being truncated :(
But we also still don't know why the actions in the list menu aren't working for me (read what I said about the txt search on my linux partition).

Oh - and I just checked that the actions on search don't work either.
And the funny thing I just discovered is if I do a search for music files on hdb6, it only finds 24 of those mp3s - but I thought it just checked the extension, so it should find 269...

Am I really the only person having problems with 2.5? What could it be? Could my locale (nz) affect it somehow?

---------
I just checked by replacing the truncated tree-items file with the one generated from your instructions, and confirmed that the behaviour of pfind reopening when closed after a "show only" button press definitely occurs (only) when the tree-items file is truncated.

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#111 Post by zigbert »

If I understand you right, it all seems to work with the given code.

In file /usr/local/pfind/func you'll find this section:

Code: Select all

-build_treeitems)
	echo -e "\c" > /tmp/pfind-treeitems$PROGPID
	if [ `cat /tmp/pfind-view$PROGPID | wc -l` -lt $MAX_LIST_ITEMS ]; then #define how many items allowed in hitlist
		for I in `cat /tmp/pfind-view$PROGPID | sed -e "s/ /{ð®Sđþ}/g"`; do
			TMP=`echo "$I" | sed -e "s/{ð®Sđþ}/ /g"`
			find "$TMP" -maxdepth 0 -printf "%p|%s|%CY/%Cm/%Cd - %CT|%M|%u\n" >> /tmp/pfind-treeitems$PROGPID
		done
		if [ "$ACCEPT_ARROW" = "false" ]; then #filenames with < or > corrupts <tree> when not UTF-8
			#check filenames for < and >
			TMP=`cat /tmp/pfind-view$PROGPID | grep "<"`
			TMP2=`cat /tmp/pfind-view$PROGPID | grep ">"`
			if [ "$TMP" ] || [ "$TMP2" ]; then
				FRAME="Info"; IMG="dialog-info"; TXT1="Search result contains file(s) with < or > in name. As long as all fileames uses charset UTF-8 there is no risk, and you can edit config file to allow these chars. If filenames uses other charset than UTF-8 Pfind will fail. Pfind will now translate < and > to ?"
			. "$PROGPATH"box_ok
			fi
			cat /tmp/pfind-treeitems$PROGPID | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/pfind-treeitems$PROGPID
		fi
	else
	 	echo "Not allowed to view more than $MAX_LIST_ITEMS items.|Edit config file." >> /tmp/pfind-treeitems$PROGPID
	fi
;;
The working code was taken from here. Play with it...
Try to hash lines to see if you can find the breaking point.

Sigmund

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#112 Post by disciple »

No, that code produces a correct pfind-treeitems file, but the actions in the list menu still don't work. I think this is an separate problem, as the actions in the list menu never work, but the tree-items file is only truncated on some searches.

I'll have a go at playing around with it to figure out how to prevent the truncated file, but I might not find time for a while :(

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#113 Post by zigbert »

I have now upgraded to Puppy 3.0.1 and got the same problem, so I guess I'll be forced to do something about it. :)

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#114 Post by zigbert »

Fixed. See main post.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#115 Post by disciple »

Great - that's much better. I was just trying to muster the enthusiasm to look at it properly :)

I'm afraid I've found another couple of bugs now though.
1. the "view in imagebrowser" list action, and the matching button, starts up gtksee, which loads everything and then crashes with a segmentation fault. Have you changed anything about the way the links are created or anything?

2. the search actions "open in text editor", "export list to text editor", and "view in imagebrowser" don't work - it starts searching and then suddenly stops and brings back the advanced search window.

I've only checked this up to Puppy 2.16.

BTW I still needed to manually set the permissions on /usr/local/bin/pfind.

User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#116 Post by richard.a »

Been using the existing dotpup I've had for a while with my rebuild of 2.10pro and 2.02r2 to save putting extra stuff into the distribution.

Work really well. Thank you :)

Richard
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#117 Post by zigbert »

richard.a
Nice to hear you find it useful

disciple
You must be the official Pfind-agent. :D
Thanks a lot!!!!!

1. I try "view in imagebrowser" and it all seems ok, until I click on a *.png in GtkSee. Other filetypes works ok ?????? I use Puppy 3.01, and I'll place this in the todolist.

2. Not working search actions will be fixed.

Sigmund

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#118 Post by zigbert »

Edit:

It seems that GtkSee crashes when path says /initrd/mnt/dev_save and file extension is png
BUT NOT ALWAYS ????

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#119 Post by disciple »

It crashes with just .jpg files for me. Must be something different about the older puppies.

I'm not sure if I tried it in the last version or two - do you know if you changed anything recently that might affect it working with gtksee?

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#120 Post by zigbert »

It's seems that the problem is the length of filename. Pfind adds the total path to the end of the name of the symlink. When it is longer than 80 chars (or something like this) it crashes.

Is it the same for you?

Sigmund

Post Reply