On the other hand, a bool variable's name can do all the describing needed; if the variable's name is "native", it's said everything I need to know - and, being a bool, I can test it naturally.  In contrast, a variable named "mode" is too vague (I/O mode ?  network vs local ? permissions ? oh! file ending, eh, who would have guessed) and having to test it with a comparison is unwieldy, especially when what you're comparing it to is 18 characters long, with mixed case and a character outside the alphabet that fingers have to reach further to hit.
Consequently, while there are cases where I'll prefer an enum to bool (e.g. if we actually suspect we might some day need to handle MS-Win files on *nix, the dream of a NewLineMode_DOS member of this enum would make a valid case for keeping it), I prefer to put the information content in the variable name and reuse a generic type.

Also, if I were designing this enum, anticipating further members to it, I'd probably make native the 0 member, as everything else needs special treatment when it's non-native.