Windows and file system abstraction - how much does it matter where something comes from?

Posted by deceze on Super User See other posts from Super User or by deceze
Published on 2010-05-18T01:25:40Z Indexed on 2010/05/18 1:32 UTC
Read the original article Hit count: 284

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 Bootcamp driver package includes file system drivers (right term?) that enable Windows to access the Mac OS HFS+ partition. AFAIK it's a 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?

© Super User or respective owner

Related posts about Windows

Related posts about filesystems