Bcrypt GUI fix

dogone reported:
Bcrypt advises that "password must have at least 9 characters" but does not accept fewer than 10. (The fix of incrementing the "must have" alert by 1 appears to have bumped the required character count by 1. IOW, the same problem + 1.). Also experienced in 417.

Fixed it, correctly this time I think.

Dogone also reported:
Zfind GUI stops responding when a search of root ("/") is executed and must be killed. Zfind remains running in the background with extreme CPU load. Searches above "/" appear to work. Also experienced in 417
Never do a file search from '/', whatever search tool you are using. There is all sorts of stuff that get searched through, like /dev /tmp /proc /sys and apart from taking ages I don't know there might be some strange side effects.
Pfind also should never offer '/' as the search path.

Dogone also reported this:
During installation of MC (Midnight Commander), PPM displayed "Examine Dependencies" button. Clicking it did nothing. MC installation was then completed with a missing dependency: "mc: error while loading shared libraries: libgpm.so.1: cannot open shared object file: No such file or directory". Also experienced in 417.
Well, where did this package come from? If it is not an official package, and it doesn't have a database entry in it, then PPM has no way of knowing what its dependencies are.


Posted on 5 Aug 2009, 19:48


Comments:

Posted on 5 Aug 2009, 19:59 by linuxcbon
file search
Doing a file search from '/' should NOT be a problem.


Posted on 5 Aug 2009, 21:33 by zigbert
Pfind search-path
What search-path do you find wise? I personally don't think /root/ would be a good choice. I can't store much in my 512mb pup_save, and I always learn new Puppy-users to store things outside the Pup_save

Sigmund


Posted on 5 Aug 2009, 21:46 by BarryK
search path
What about /mnt/home as the default?
Except when it points to '/', then use /root -- that would be a full hd install situation.

The problem with /mnt/home though, is it would be the top of an entire partition. Probably not such a good idea.

If it defaults to /root, it can be changed anyway, to whatever the user wants.

I'm just thinking that the default should not be somewhere that is going to bog the search tool down for a long time and the user wonders what is going on.

Personally, I open a terminal from rox, in whatever directory I want to search, then start zfind and it defaults to that directory.

Perhaps with Pfind, you could get it to default to /root, but then Pfind will remember whatever the user has changed it to and use that automatically next time (if it's mounted of course, otherwise fall back to /root).



Posted on 5 Aug 2009, 22:36 by dogone
422 observations
Thanks for sorting through this stuff, Barry.

422 PPM's "find" command locates "mc-4.6.1" in the "puppy-4" repro. At least it does after performing an "update".

No matter the wisdom of searching from "/", Pfind and other search utilities can do it. Zfind cannot. The inability thus appears a shortcoming. In any case, Zfind ought not to accept a search parameter that results in loss of control and a very nasty rogue process. Puppy can do better.



Posted on 5 Aug 2009, 23:03 by BarryK
mc dependency
MC is in the puppy3 repo.
Looking in /root/.packages/Packages-puppy-3-official:

mc-4.6.1|mc|4.6.1||Filesystem|2267K|pet_packages-3|mc-4.6.1.pet|+gpm|midnight commander console file manager|

Shows that 'gpm' package is a dependency. However there is no entry for gpm in Packages-puppy-3-official, although gpm-1.20.1-1.pet is on ibiblio.

Ok, I have added an entry for gpm into Packages-puppy-3-official. That will be fixed in 4.3beta1.

You can fix the problem right now by downloading and installing gpm-1.20.1-1.pet from pet_packages-3 directory at ibiblio.



Posted on 5 Aug 2009, 23:08 by zigbert
default search-path in Pfind
Barry

The search-path issue has been raised now and then, and opinions differ. I see all points, but I don't see a clear solution.

What we really need is information to the user and a progress bar. At the moment I'm not clever enough to show the progress of 'find'.

The default search-path(s) are defined in /root/.pfilesearch/pfilesearchrc. Please change it to whatever you find most logical.

Sigmund




Posted on 6 Aug 2009, 15:15 by disciple
search-path in Pfind
> No matter the wisdom of searching from "/", Pfind and other search utilities can do it. Zfind cannot.

It is painful in pfind though - that's why I suggested the ability to exclude multiple directories.

> What about /mnt/home as the default?

IMO that might be all right. I don't think $HOME makes sense until Puppy is multi-user. But I think / is the best... just need to exclude all those pesky locations... and probably /mnt/network too.

But if the default location isn't /, surely a search-path field should be added to the "simple" pfind gui?


Posted on 7 Aug 2009, 19:37 by zigbert
Faster Pfind
I have uploaded a new Pfilesearch (1.17). I have excluded /initrd by default which gives me a much faster search on my frugal system. I have still defined / as the default search-path.

Sigmund


Posted on 7 Aug 2009, 19:51 by BarryK
re faster pfind
Zigbert,
I typically have 3 or 4 partitions mounted in /mnt -- if the default search is from /, will all those mounted partitions get searched too? If so, it will take ages.



Posted on 7 Aug 2009, 21:44 by zigbert
re faster pfind
Barry
Yes, /mnt will be included in the search.
I store 'all' my stuff in /mnt/sda6, so unlike you, I most often want to search in my /mnt directory.

I don't have such a huge file collection as you, but still rather big.
Look at this: 
# ls -R / | wc -l

318577

# ls -R /initrd | wc -l

218181

# ls -R /mnt | wc -l

41543


What I experienced was this: 
# time find -P "/" -path '/initrd' -prune -o  -iname "*tnt - 10*" 

/root/tnt/TNT - 10.000 lovers (in one).mp3

real    0m1.032s

user    0m0.400s

sys     0m0.496s



# time find -P "/" -iname "*tnt - 10*" 

/root/tnt/TNT - 10.000 lovers (in one).mp3

/initrd/pup_rw/root/tnt/TNT - 10.000 lovers (in one).mp3

real    0m2.640s

user    0m1.100s

sys     0m1.008s

It would be better if we could exclude /dev and /proc too, but I can't find a solution to exclude more than 1 item in the 'find' command. On the other hand, /dev and /proc didn't affect the exec time that much.

Sigmund