So in other news: It appears that leaving my NTFS partition unmounted yields no more kernel panic. Take it up with NTFS-3g folk?
-mike On Dec 18, 10:18 am, timeless <[email protected]> wrote: > On Thu, Dec 18, 2008 at 3:23 PM, Erik Larsson <[email protected]> wrote: > > From the user's point of view, a kernel panic is the among the worst > > things that can happen as you potentially lose everything that you're > > currently working with, > > everyone assumes this. but it's actually wrong. > the worst thing is to have stuff you weren't working on corrupted in > ways you don't recognize until it's too late :) > and w/ a file system driver, stuff like that really could happen > <insert plug for ZFS here, including some great videos, which can > probably be loaded via youtubefs :)>. > > http://images.google.com/images?q=sad+mac(when your computer doesn't > boot, you're a lot less happy than when it just reboots) > > wrt lost data, i've moved to using ff3 and googledocs (and gmail), > which mean that my data is automatically saved while i'm not thinking > about it. > > even computer games have autosave (although sometimes they > intentionally don't for certain points) > > none of this means that i like it when my systems panic. i still have > a bone to pick w/ a certain firewall vendor (i can't pick it w/ them > because due to encryption below the os level, i can't get a dump for > the panic). the good thing about panics in general is they upset > customers and the customers send strong feedback and the engineers try > to analyze (and fix) them asap. > > the other nice thing about panic markers in open source is that people > are free to search for them and audit them to try to figure out what > assumptions they're making - this is similar to what i was doing (i > was searching for malloc/realloc, but looking for panic() is just as > easy). if you think that a panic() could happen because of something > legal, try to build a testcase - from what i've seen w/ macfuse, that > should actually be tolerable (just save your work before you start > ;-). and once you have a nice testcase which explains why the input > should be legal and what the expected results are, you can file a bug > (and maybe even try to patch it). > > > Either way, thanks for an enlightening discussion. :) > > :) > > thinking about open(x, 0), it sounds like a stat shortcut to search > for bad files/paths > EACCES, ENAMETOOLONG, ENODEV*, ELOOP, ENOMEM, EMFILE, ENFILE > (* the explanation here makes no sense) > > i seem to recall code which did something like that (don't ask me where) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
