Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have come across the following phenomenon and would like to know how leaky Windows' file system abstraction is or if there's something else involved.

I partitioned the hard disk of my MacBook Pro and installed Windows 7 (64 bit). The Boot Camp driver package includes file system drivers that enable Windows to access the Mac OS HFS+ partition. It's read-only access, but it works.

Now, I have some disk images of stuff I usually install, so I grabbed a copy of Daemon Tools to mount them. When I mount an image saved on the HFS+ partition, about two out of three installers on these disks (usually InstallShield) crash with all sorts of weird errors. Most are just gibberish that lead to all sorts of non-solutions on Google, one was "This application is not the right type for your computer, check if you need 32 or 64 bit versions."

When moving the image files to another Windows 7 computer on the network and mounting them from the network share, they work fine.

My question now is, why do applications behave differently depending on whether the read-only image file, which should be abstracted away through the read-only virtual Daemon Tools drive, is located on a read-only HFS+ partition or on a Windows network share?

And I'll just roll this into the question as well since I was wondering: Does the file system of a network share matter? Does the client system need to understand the file system of the share host or is that abstracted away in SMB?

share|improve this question
    
Do you have any examples of programs other than Daemon Tools behaving contrary to expectation? It's not totally implausible that Daemon Tools isn't going through the "normal" APIs to access the filesystem since it's a tool for managing storage. –  Stephen Jennings May 18 '10 at 5:34
    
@Stephen No, I don't, mostly because I'm not spending a lot of time in Windows. If it's a Daemon Tools issue and that's the answer, that's fine too. Your edit is incorrect BTW, I can mount the image just fine and read files on it, even executables in it execute. Just some of them fail with nonsense errors. –  deceze May 18 '10 at 5:55

1 Answer 1

up vote 1 down vote accepted

why do applications behave differently depending on whether the read-only image file, which should be abstracted away through the read-only virtual Daemon Tools drive, is located on a read-only HFS+ partition or on a Windows network share?

I expect the answer is "flaky HFS+ filesystem drivers". You'll get a better test if, when one of these virtual-ISO-installs fails, you copy the ISO to the local NTFS drive. Then mount the NTFS copy and retry the installation -- if it fails there, you've got a bad ISO; if it doesn't, you're getting bad reads when coming off the HFS+ partition.

And don't discount the bad-ISO scenario. Verify the ISO through some other means -- MD5 or SHA hashes are good for that.

An interesting experiment might be to calculate the hash once, then do something else disk-intensive (to clear drive cache), then repeat 10 or 20 times. If your HFS+ drivers aren't getting the reads right, you'll be getting a lot of different values.

Does the file system of a network share matter? Does the client system need to understand the file system of the share host or is that abstracted away in SMB?

Not really. SMB fileshares provide their own "filesystem" called SMB or CIFS. To the client computer (the one accessing the network share), CIFS is the filesystem. The server computer (the one providing the network share) is the only system aware of the actual filesystem underlying that share (be it NTFS, FATx, ext2+, HFS+, whatever).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.