Opened 18 years ago
Closed 18 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: | ||
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)
Change History (2)
by , 18 years ago
Attachment: | Directory.cpp.diff added |
---|
comment:1 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.