Mike, can you please try the latest Beta Release for Leopard (2.1.5 as of this writing) and see if you can still reproduce the panic? Besides the lack of a panic, also make sure that whatever you are trying actually works too.
On Dec 19, 3:07 am, mike glass <[email protected]> wrote: > 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(whenyour 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 -~----------~----~----~----~------~----~------~--~---
