On Fri, 19 Dec 2008, mike glass 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?
If VMware uses no open() flag then the MacFUSE kernel module should return
EINVAL instead of crashing.
However I doubt this is the case but probably it passes an unsupported flag
(mmap?), in which case ENODEV should be returned if it's not supported.
But then why it's logged as 0 flag?
Szaka
--
NTFS-3G: http://ntfs-3g.org
> 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
-~----------~----~----~----~------~----~------~--~---
