Find by folder not working

[HAL]

If I do a find by folder nothing is found but if I just enter the folder name leaving "All files and folders" dropdown box at default it does find the folder.

1. Open Find.
2. Select from drop down box "Folder".
3. In the box type a folder name eg, sounds. Click Search.

Result: Nothing found but in step 2 if left at default "All files and folders" it will find sounds. Also in step 2 if any other type is selected eg, jpeg image and the box left blank, it will find all jpeg images or if a name is entered it will find the jpeg image of that name. So it is not working only if "Folder" is selected in the drop down box.

[HAL]

I was testing in hrev38903 GCC4 hybrid.

[humdinger]

Don't know why and where it goes wrong, but the reason is that the folders on the boot partition don't have their file type set, which is empty instead of "application/x-vnd.Be-directory". All folders on my second BFS partition do have it set and the query works there. Doing a "Force identify" (SHIFT+rightclick) on a folder corrects the issue. A " mimeset /boot/* " will set all file types on the boot partition. Something that AFAIK is supposed to be done while installing.

[HAL]

Cannot reproduce this anymore in latest alpha4 release candidates.

[diver]

Can't reproduce either. Closing.

[HAL]

I am reproducing this again with hrev45954 gcc2 hybrid.

[HAL]

Replying to humdinger:

Don't know why and where it goes wrong, but the reason is that the folders on the boot partition don't have their file type set, which is empty instead of "application/x-vnd.Be-directory". All folders on my second BFS partition do have it set and the query works there. Doing a "Force identify" (SHIFT+rightclick) on a folder corrects the issue. A " mimeset /boot/* " will set all file types on the boot partition. Something that AFAIK is supposed to be done while installing.

I tried "mimeset /boot/* " and as humdinger says it will enable find by folder. Is this not been done automatically at install?

[humdinger]

Would it be OK to change the "mimeset -apps -f" in ​mime_update.sh and add the remaining folders (in /boot/system and below /boot (common, develop, home, optional))?

Sure that takes a dozen additional seconds, but it's the right thing to do, innit?

[jscipione]

Replying to humdinger:

Would it be OK to change the "mimeset -apps -f" in ​mime_update.sh and add the remaining folders (in /boot/system and below /boot (common, develop, home, optional))?

That would be an expensive band aid and not a proper fix. To properly fix this we'll need to set the

application/x-vnd.Be-directory

attribute to every directory in the system, not just those in /boot. Right now mime_update.sh only sets the attributes of applications on the system and a few other files so this would be a big change. Perhaps this attribute could be set to folders in the build system or during install?

[jscipione]

Thinking about this a bit more, even setting the

application/x.vnd.Be-directory

attribute on every folder in the system is going to be fragile since directories can get created in a number of ways and the attribute is bound to get out of sync with reality. Perhaps someone can correct me here if I'm wrong.

I'm not sure how well this feature worked on BeOS, but, perhaps a better solution would be to update the Find dialog filter based on the stat information rather than look for the

x-vnd.Be-directory

attribute, it would even work on FS's that don't support attributes.

[anevilyak]

Replying to jscipione:

attribute on every folder in the system is going to be fragile since directories can get created in a number of ways and the attribute is bound to get out of sync with reality. Perhaps someone can correct me here if I'm

wrong.

The attribute would normally get set the same way as it does on any other untyped filesystem object, namely via mime sniffing rules. As such, the risk of them getting "out-of-sync" is no different/greater than for any other type, so this line of reasoning really doesn't make sense.

I'm not sure how well this feature worked on BeOS, but, perhaps a better solution would be to update the Find dialog filter based on the stat information rather than look for the

That would completely break most of the benefits of BFS queries, as it'd reduce Find to having to crawl the whole filesystem, doing a stat() on each file. This would be hideously inefficient.

[jscipione]

Replying to anevilyak:

Replying to jscipione:

attribute on every folder in the system is going to be fragile since directories can get created in a number of ways and the attribute is bound to get out of sync with reality. Perhaps someone can correct me here if I'm wrong.

The attribute would normally get set the same way as it does on any other untyped filesystem object, namely via mime sniffing rules. As such, the risk of them getting "out-of-sync" is no different/greater than for any other type, so this line of reasoning really doesn't make sense.

Thanks for that, I tried to find if BFS set this attribute for you when you create a directory but couldn't locate the code in question. A sniffing rule makes sense.

I'm not sure how well this feature worked on BeOS, but, perhaps a better solution would be to update the Find dialog filter based on the stat information rather than look for the

That would completely break most of the benefits of BFS queries, as it'd reduce Find to having to crawl the whole filesystem, doing a stat() on each file. This would be hideously inefficient.

I'd imagine it would perform as well as

find -type d

So, given that the attribute can be kept in sync and it is faster to use attributes, I refer back to comment 9.

[bonefish]

FWIW, the mime_update.sh script is gone with package management. It simply wouldn't work, since most folders and files under /boot/system and /boot/common are read-only. On the upside, both the Haiku build system and haikuporter run mimeset before creating a package. So all packaged folders do already have the attribute. Folders that don't come from packages still don't, though.

A MIME sniffer rule doesn't exist for directories, since those operate on data. Directories and symlinks are handled explicitly by the MIME sniffing code. In BeOS the registrar crawled the file system to sniff files in the background, so everything was properly identified eventually. In Haiku we don't do that. Originally the plan was to introduce the same mechanism eventually, but since the whole query support is misplaced in the file systems and should rather be put into a separate server (like the index server Clemens implemented), that might not happen after all.

[humdinger]

Replying to jscipione:

Would it be OK to change the "mimeset -apps -f" in ​mime_update.sh...

That would be an expensive band aid and not a proper fix. To properly fix this we'll need to set the

application/x-vnd.Be-directory

The not-set folder type is just the tip of the iceberg. No files besides the applications and the few files touched in the mime_update.sh have their MIME type set. So a query for any file type returns nothing ATM. But as: bonefish:

FWIW, the mime_update.sh script is gone with package management. [...] On the upside, both the Haiku build system and haikuporter run mimeset before creating a package.

We seem to soon be all set for new Haiku installations in the near future.

(like the index server Clemens implemented)

Oh, it's already implemented? A full-fledged index_server would be awesome: full-text search for all "translatored" file types... mmmmh.

[bonefish]

Replying to humdinger:

(like the index server Clemens implemented)

Oh, it's already implemented? A full-fledged index_server would be awesome: full-text search for all "translatored" file types... mmmmh.

I don't know what its status is. From his commits back then I got the impression that the indexing itself was working. Obviously at least the integration with the query mechanism (or at least Tracker's Find functionality) is still missing.

[bipolar]

Just tested this on hrev56395 (32 bits). Cannot reproduce. Might have been fixed already?