Re: Changing FS type reported by Wine
Duane Clark wrote:
Stephen Mollett wrote:
I'm using ReiserFS. I've also tried on a 40GB ext3 filesystem on a spare drive. The error comes from VirtualDub, which believes that it's running on a FAT32 filesystem (obviously that's what Wine reports to any program that asks what FS type a drive is). I've tried working around it by using vdub's 'segmented AVI' feature (which creates multiple AVIs <= 2GB) but I can't use these successfully under Linux.
In the file wine/files/drive.c, in the function GetVolumeInformationW() (down around line 1965), is this:
if (fsname && fsname_len) { /* Diablo checks that return code ... */ if (DOSDrives[drive].type == DRIVE_CDROM) { static const WCHAR cdfsW[] = {'C','D','F','S',0}; strncpyW( fsname, cdfsW, fsname_len ); } else { static const WCHAR fatW[] = {'F','A','T',0}; strncpyW( fsname, fatW, fsname_len ); } fsname[fsname_len - 1] = 0; /* ensure 0 termination */ }
That appears to hardcode the filesystem "name" to FAT. You might try changing that to NTFS. That assumes that this is the call your app is using to determine filesystem type.
I assume you have already determined that ReiserFS supports files larger than 2GB?
Well thats a patch that shouldn't go into cvs. <g> If it does "fix" the application though then there should be some way for wine to do it the "right way". The way I see it there are two ways to do this. 1.) wine should try to set the fsname to NTFS if underlying file system can support files sizes > 4GB. 2.)There should be a conf file option for NTFS along with MSDOS, unix and win95. The difficulty with wine trying to do this automaticly is that it would need to find the file system type of the current directory and not the root. This is of course because of the way the unix file system works. The current directory could very well be an MSDOS drive while the root drive is an ext3 and this function is only aware of the root drive. AFAICS Having it as a config option is easier to implement and removes the problem from the developers hands.<g> For myself I (think I) could implement it as a config option but Iwould prefer that wine could deal with it automaticly. If anyone has any suggestions I would appreciate it. -- Tony Lambregts
Tony Lambregts wrote:
Well thats a patch that shouldn't go into cvs. <g> If it does "fix" the application though then there should be some way for wine to do it the "right way". The way I see it there are two ways to do this.
1.) wine should try to set the fsname to NTFS if underlying file system can support files sizes > 4GB.
2.)There should be a conf file option for NTFS along with MSDOS, unix and win95.
The difficulty with wine trying to do this automaticly is that it would need to find the file system type of the current directory and not the root. This is of course because of the way the unix file system works. The current directory could very well be an MSDOS drive while the root drive is an ext3 and this function is only aware of the root drive.
AFAICS Having it as a config option is easier to implement and removes the problem from the developers hands.<g>
For myself I (think I) could implement it as a config option but Iwould prefer that wine could deal with it automaticly. If anyone has any suggestions I would appreciate it.
Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive. derek
Derek Broughton wrote:
Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive.
According to MSDN, "FAT" and "NTFS" are both legitimate return values for the filesystem name from GetVolumeInformation (though it does not mention what other possibilities might also be valid). Wine hardcodes this to always return FAT (or CDROM). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base... Since it is hardcoded, I don't know how you would "set up new drive letters for the specific file systems you needed." An option in ~/.wine/config, on the otherhand, would make this easy.
Duane Clark wrote:
Derek Broughton wrote:
Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive.
According to MSDN, "FAT" and "NTFS" are both legitimate return values for the filesystem name from GetVolumeInformation (though it does not mention what other possibilities might also be valid). Wine hardcodes this to always return FAT (or CDROM).
Surely from Windows p-o-v _no_ other return values should be legitimate. Can windows natively read any other types? I don't think so.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base...
Since it is hardcoded, I don't know how you would "set up new drive letters for the specific file systems you needed." An option in ~/.wine/config, on the otherhand, would make this easy.
I understand that it _is_ hardcoded, but it seems to me that the simplest solution is to return the value specified in the config file for each drive. As Tony says, if you have drive X: pointing to a directory on one filesystem but whose subtree contains another filesystem, returning the value for the root drive may not always be right, but as I see it, that would be an impossible situation under Windows, so not one that Wine really needs to deal with.
On Thursday 26 December 2002 10:35 am, Derek Broughton wrote:
Duane Clark wrote:
Derek Broughton wrote:
Windows which _doesn't_ understand the concept of different file systems under a single drive. Surely from Windows p-o-v _no_ other return values should be legitimate. Can windows natively read any other types? I don't think so.
Hmm, perhaps not out of the box, but surely, what with reparse-points, DFS, "offline files", hard-links, and other such features, it's not so simple as "fs(root)==fs(arbitrary_subdir(root)) && fs(root) in [fat, ntfs]" in all cases, is it? And then there is support for netware, appletalk, and even nfs.... Also, itsn't it totally possible, even limiting ones self to documented functionality in the DDK, to produce 3rd-party FS drivers and install them (note, that I didn't say easy :) )? The above just covers what you can get from Microsoft... For example, doesn't Oracle provide some FS driver (or perhaps they gave up on that plan...)? Regardless, I don't see anything wrong with the current approach, which could be extended to support NTFS, or some new driver. Getting the emulated FS type from the native FS type seems like a limitation more than a feature to me... or am I missing the idea of this? -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot
Greg Turner wrote:
On Thursday 26 December 2002 10:35 am, Derek Broughton wrote:
Duane Clark wrote:
Derek Broughton wrote:
Windows which _doesn't_ understand the concept of different file systems under a single drive.
Surely from Windows p-o-v _no_ other return values should be legitimate. Can windows natively read any other types? I don't think so.
Hmm, perhaps not out of the box, but surely, what with reparse-points, DFS, "offline files", hard-links, and other such features, it's not so simple as "fs(root)==fs(arbitrary_subdir(root)) && fs(root) in [fat, ntfs]" in all cases, is it? And then there is support for netware, appletalk, and even nfs....
Also, itsn't it totally possible, even limiting ones self to documented functionality in the DDK, to produce 3rd-party FS drivers and install them (note, that I didn't say easy :) )? The above just covers what you can get from Microsoft... For example, doesn't Oracle provide some FS driver (or perhaps they gave up on that plan...)?
Regardless, I don't see anything wrong with the current approach, which could be extended to support NTFS, or some new driver. Getting the emulated FS type from the native FS type seems like a limitation more than a feature to me... or am I missing the idea of this?
Tony seemed to think it was more difficult. I still don't see how, even if you want to support all the third-party possibilities, it's possible to have two files systems under one drive in Windows.
On Thursday 26 Dec 2002 23:24, Derek Broughton wrote:
I still don't see how, even if you want to support all the third-party possibilities, it's possible to have two files systems under one drive in Windows.
On Windows 2000, it's possible to mount a FAT or FAT32 (or NTFS, of course) partition under an empty directory on an NTFS drive (Microsoft call it Mount Points; it's accessible from the disk administration MMC module - you can either assign a drive letter to a partition or mount it at a mount point or both). Stephen
Why should we obey to all windows limitations ? Remember, Wine Is Not an Emulator. Other point, you can read&write on NTFS volumes using several tools as Ntfsdos from http://www.sysinternals.com
Surely from Windows p-o-v _no_ other return values should be legitimate. Can windows natively read any other types? I don't think so.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base...
Since it is hardcoded, I don't know how you would "set up new drive
letters for the specific file systems you needed." An option in ~/.wine/config, on the otherhand, would make this easy.
===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Derek Broughton wrote:
Tony Lambregts wrote:
Well thats a patch that shouldn't go into cvs. <g> If it does "fix" the application though then there should be some way for wine to do it the "right way". The way I see it there are two ways to do this.
1.) wine should try to set the fsname to NTFS if underlying file system can support files sizes > 4GB.
2.)There should be a conf file option for NTFS along with MSDOS, unix and win95.
The difficulty with wine trying to do this automaticly is that it would need to find the file system type of the current directory and not the root. This is of course because of the way the unix file system works. The current directory could very well be an MSDOS drive while the root drive is an ext3 and this function is only aware of the root drive.
AFAICS Having it as a config option is easier to implement and removes the problem from the developers hands.<g>
For myself I (think I) could implement it as a config option but Iwould prefer that wine could deal with it automaticly. If anyone has any suggestions I would appreciate it.
Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive.
Right now I am working on a solution that leaves it in the hands of the user (the ~/.wine/confige option). If someone at a latter date wants to implement a dynamic solution that is up to them. After thinking about it I have come to the conclusion that the user should know if the directory that he is writing to is fat or not. The default config option should still be win95 and the documentation should be clear enough that the user will know when to use it. -- Tony Lambregts
participants (6)
-
Derek Broughton -
Duane Clark -
Greg Turner -
Stephen Mollett -
Sylvain Petreolle -
Tony Lambregts