Opened 12 years ago

Closed 12 years ago

#1034 closed bug (fixed)

False positives by BDirectory::Contains()

Reported by: jonas.kirilla Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Storage Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

In Haiku, if you drag things out of ~/boot/home/config/, e.g. /boot/home/config/fonts, Tracker gives you the erroneous error message (how ironic) "If you move the mime settings Haiku may not behave properly! Are you sure you want to do this? " Regardless of what you move, the error message is about the 'mime settings'.

Tracker / FSUtils.cpp / ConfirmChangeIfWellKnownDirectory() calls StorageKit / Directory.cpp / BDirectory::Contains() which gives a false positive since it can't find beos_mime in B_COMMON_SETTINGS_DIRECTORY. (I think this is what happens.)

If you create beos_mime in B_COMMON_SETTINGS_DIRECTORY (/boot/common/config), BDirectory comes to the right conclusion, which is that this folder (/boot/common/config) does not contain the entry that is being moved (/boot/home/config/fonts), whereas if /boot/common/config/beos_mime is missing, it concludes that the one contains the other, which is obviously wrong.

I've rewritten BDirectory::Contains() to be more clear: http://www.kirilla.com/haiku/Directory.cpp.diff

Tracker's error messages when moving stuff below /boot/home/config seem right now, with my changes, and you can move most things, like /boot/home/config/fonts, without interruptive alerts, but I haven't done any testing beyond that to prove that the code does the right thing in all circumstances.

Attachments (1)

Directory.cpp.diff (1.9 KB) - added by jonas.kirilla 12 years ago.

Download all attachments as: .zip

Change History (2)

Changed 12 years ago by jonas.kirilla

Attachment: Directory.cpp.diff added

comment:1 Changed 12 years ago by axeld

Resolution: fixed
Status: newclosed

Thanks for the patch! The problem was caused by BDirectory::Contains() returning true if the directory itself was not initialized, but the entry existed. I've not used your patch directly, but simplified the version in the tree differently; I've kept "result" around, and I think it's even clearer this way, but YMMV. BTW our coding style doesn't like the space between "!" and the following text a lot :-) Fixed in hrev20221.

Note: See TracTickets for help on using tickets.