No, the situation is not what people so far are "understanding" it to be. Earlier, I had said open *call chain* (which means, somewhere in the processing of open... deep inside the vfs layer), which is ****NOT**** the same as "open(path, 0)", which people seem all too happy to pontificate on.
We aren't talking about supported or unsupported flags here. We are talking about something that shouldn't happen. Based on the evidence presented so far, this is in Apple's kernel extension that handles disk images, not in VMware. If you look in the very first version of MacFUSE: http://code.google.com/p/macfuse/source/browse/tags/fuse-0.1.0b004/fusefs/fuse_file.h See the call to panic("What kind of a flag is this?") ? In other words, this intentional panic has always been there, but hasn't been triggered to my knowledge in the 2 years of MacFUSE's existence. That is exactly what such panics are for: to find out when something that should "never" happen happens. MacFUSE will have to adapt to this though. Amit On Dec 19, 5:02 am, Szabolcs Szakacsits <[email protected]> wrote: > 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(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 -~----------~----~----~----~------~----~------~--~---
