C: detected as network share

[imanolbarba]

Hello, I've been trying to install Office 2007, and it has been complaining that it won't install on network shares.

I can see that C: appears to be a network share, that may be possible since this computer's home folder is mounted via NFS.

I've tried to add a second D: drive, and setting type to Local Hard Drive, but it is still being detected as a Network share, setting type to CDROM doesn't work either, and setting another drive which is detected as a CDROM to any other type is also not working.

That makes me believe that type detection is currently being IGNORED by wine

What can I do to override type detection?

I'm using wine 1.4.1

[dimesio]

First, your Wine version is old and no longer supported. Upgrade to at least the latest stable release.

Beyond that, from what you describe it sounds like Wine is correctly detecting that the drive is a network share. If Microsoft has designed Office to refuse to install to a network share there's nothing anyone here can do about it.

[imanolbarba]

I'll try upgrading to the latest stable version, nonetheless, quoting myself:

I've tried to add a second D: drive, and setting type to Local Hard Drive, but it is still being detected as a Network share, setting type to CDROM doesn't work either, and setting another drive which is detected as a CDROM to any other type is also not working.

That makes me believe that type detection is currently being IGNORED by wine

I know I can't work around Office, but Wine is not behaving properly, as I stated on the first post. It should correctly override the media type if specified manually, I'll check if it works with the latest version.

[dimesio]

Turns out to be a known bug: http://bugs.winehq.org/show_bug.cgi?id=17619

[imanolbarba]

Oh I hadn't found that bug report, I'll keep track of it.

Thank you very much!

[oiaohm]

dimesio I really do need to post on that bug. The problem is more complex than the wine developers are seeing.

Drive C under Windows in fact can be a network share. Microsoft Windows Preinstallation Environment (Windows PE) option.

So this is not exactly a bug. Wine is just showing up as a normal Microsoft Windows Pre-installation Environment in this case so showing all the limitations to prevent accidental installation of applications in wrong place.

Steam in fact recommend against installing applications on network share. Reasons are locking under Windows. Steam recommends installing on a real local drive then moving applications to network share.

Yes there are also locking issues with NFS. imanolbarba sorry but this is a really big question should this even be an option. Are you going to be happy imanolbarba if wine accept override it but due to locking delays and other things about being on network share you have operational disasters?

Now correct way to network windows drive c with real windows is iscsi http://windowsdiskless.wordpress.com/

Options with Linux using wine. http://alexeytorkhov.blogspot.com.au/20 ... mages.html Single file on the nfs mounted by loopback or network block device.

Sorry some things have to be done like they are done under windows or we are playing with very big fire. Its like users having issues installing programs onto ntfs or fat they don't provide the options wine required. Having wine lie that nfs is not network share will be a really bad thing.

type detection is not 100 percent ignored. Manual type setting only goes so far. Yes setting a local drive to a network share will work. Setting a local area to cdrom will work. Setting a cdrom to a hard drive will not work. Harddrives don't have eject buttons. Yes ejection is a different signal to unmounted and a Windows application receiving ejection signal from a harddrive would be highly confused.

imanolbarba basically there is some built in sanity testing. The option you are attempting is going against sanity. Yes it would be good if winecfg did report when a change is rejected on grounds of this is insane.

[imanolbarba]

I'm doing a patch to make wine be aware of type overriding in winecfg, so far it looks promising. This should allow users with network shares to get their volumes recognized as DRIVE_FIXED not DRIVE_REMOTE.

If changing drive type is against sanity, they should remove the option from winecfg, not leave it to do nothing at all.

I believe that wine developers won't be interested in this patch since even that it is programmed correctly, it is just a hack to override the default behaviour.

If someone is interested, I can send it by email at imanolbarba <at> gmail <dot> com

[imanolbarba]

So far it works, it looks into HKLM/Software/Wine/Drives to see if an entry regarding the drive exists and returns the type set there, otherwise, resumes normal behaviour of GetDriveTypeW

I still have to do more testing.

[oiaohm]

imanolbarba if you notice the bug is now closed. I am sorry about that.

The problem here is what wine is doing is correct. What is required is a feature request. This would be many times more complex to implement.

If changing drive type is against sanity, they should remove the option from winecfg, not leave it to do nothing at all.

But that is a different bug. Like changing a local drive to pretend to be a network share is safe. The reverse is not without checking that the file system is upto it.

imanolbarba wine has a anti-hack rule to all upstream patches. Its very easy to override the flag. But that alone is a hack. What has to be address most of all is the fact that items like NFS mounted particular ways have very lax to no file locking at all. Now windows applications reported that they are on DRIVE_FIXED expect file locking to work.

We have a simplar problem with people install wine on ntfs or fat file systems locally. In fact its almost the identical problem. Yes the programs install. Yes the programs appear to run. Yes the program screw up because there update software and other software bits don't work correct due to locking missing.

imanolbarba basically the patch you have done is a house of cards. Yes it looks good but it can fall down at a moments notice. So at best imanolbarba you have small part of the patch required.

Yes its a feature request check sanity of c drive location stop users from blowing feet off.

imanolbarba if you go into winecfg you will notice the option to change c: is greyed out. Its stuck on autodetect. This is no some random mistake. This was intentionally done due to people placing drive_c on nfs and other sharing and switching it to local harddrive and having very bad results.

Basically I could sit back and say nothing and you will learn what you are doing is a bad thing sooner or latter.

imanolbarba the wall you are against is a feature is not greyed out in winecfg for no reason. If there was no issue it would have been set a long time ago.

imanolbarba basically all you have done so far is put wine back to how it was originally. Completely missing why it the way it is today.

imanolbarba in fact I would be very happy to see someone take up the challenge of implementing sanity checks for drive_c folder location. It would prevent support issues from ntfs, fat, nfs and smb. Yes samba file servers some people do use as well.

[imanolbarba]

Yes, you're right, it goes way beyond returning another drive type, I understand it now.

I managed to give the option to override disk type (not path), I understand that c: is greyed out for a reason, the problem is that adding a d: drive and making it a hard drive (not a network share) doesn't work, that's what I was trying to fix.

The result is that it doesn't work. Drive type is returned correctly, but it must call some soubroutines later that are dependant on that type and fail, or maybe I'm missing something else.

I've given up on this patch, I thought it would be as simple as overriding disk type and it is beyond my skills.

Maybe I'll file the bug (I'm not the original poster of the bug report), but focusing on type overriding not working (which is not greyed out on drives other than c:, but doesn't work anyway)

[oiaohm]

The result is that it doesn't work. Drive type is returned correctly, but it must call some soubroutines later that are dependant on that type and fail, or maybe I'm missing something else.

There are a list of what are called silent failures. The silent failure are the major hazard. This is where a network share might responded everything is fine but its not. Like if you are running NFSv2 on a windows server for some bad reason you ask for exclusive access to a file and its reported as you have it when you don't. So the subroutines report to application as working when they are not working.

Gets worse under windows some functions are meant to be no-ops on network shares. DRIVE_FIXED and DRIVE_REMOTE and so on really tell you want functions work and what functions return OK even that they have not worked at all.