See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Vitaliy closed this bug, saying it's an application bug that it depends on seeing NTFS file system type for certian program features. I don't think it should be a WONTFIX, as the only reason that change was introduced was to enable _another_ program to install successfully.
Is there any reason we can't allow the reported file system to be changed? I'm sure there are other applications that test for it and change their behavior according to the file system type. A quick google search shows at least one application that does (http://boards2.sega.com/sega_board/viewtopic.php?p=2669064&sid=449f531c5...). That install will likely now fail in Wine, because of this behavior.
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due to flaky NTFS support by some Linux distributions.
James McKenzie
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due to flaky NTFS support by some Linux distributions.
James McKenzie
No, it's unrelated.
Previously, we reported the file system type to be NTFS for hard disk mounts. Now we report the file system to be UNIXFS, because, e.g., the .Net 2.0 installer tries to do NTFS specific stuff on the disk, and with UNIXFS (which it doesn't recognize), it doesn't. The problem is some other apps DEPEND on seeing NTFS to work, e.g., Total War (downloading the demo now to test), and in the case of this bug, DVD Shrink. It's not using any NTFS specific features, and it's not using a 'real' NTFS mount through NTFS-3G.
2009/4/6 Austin English austinenglish@gmail.com:
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due to flaky NTFS support by some Linux distributions.
No, it's unrelated.
Previously, we reported the file system type to be NTFS for hard disk mounts. Now we report the file system to be UNIXFS, because, e.g., the .Net 2.0 installer tries to do NTFS specific stuff on the disk, and with UNIXFS (which it doesn't recognize), it doesn't. The problem is some other apps DEPEND on seeing NTFS to work, e.g., Total War (downloading the demo now to test), and in the case of this bug, DVD Shrink. It's not using any NTFS specific features, and it's not using a 'real' NTFS mount through NTFS-3G.
If I interpret it correctly, the user reporting bug 17938 is trying to use a native NTFS filesystem with Wine, which we already know is a bad idea :)
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files), then we might just have to make this configurable, possible on a per-app basis.
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type (separate from disk type, as is suggested in Comment #7 on 17938). It shouldn't be important for floppies or even CD-ROMs, but the options could be: - Default (autodetect, fall-back to unixfs) - FAT12 (floppies) - FAT16 - FAT32 - NTFS (probably don't need different versions on NTFS) Possibly restrict these to CDROM type: - ISO9660 - UDF
Unless someone can come up with a better default than unixfs :)
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type (separate from disk type, as is suggested in Comment #7 on 17938). It shouldn't be important for floppies or even CD-ROMs, but the options could be:
- Default (autodetect, fall-back to unixfs)
- FAT12 (floppies)
- FAT16
- FAT32
- NTFS (probably don't need different versions on NTFS)
Possibly restrict these to CDROM type:
- ISO9660
- UDF
Unless someone can come up with a better default than unixfs :)
Why not make the default what the filesystem actually is? Eg. if the FS is FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report unixfs; etc. The registry/winecfg can then be used to override the per-drive type if it causes problems with certain apps.
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type
Why not make the default what the filesystem actually is?
Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
Remco
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type
Why not make the default what the filesystem actually is?
That may be a lot of work. Until there's an application that needs it, we'd be better off simply allowing setting the file system type.
-- -Austin
Remco remco47@gmail.com writes:
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type
Why not make the default what the filesystem actually is?
Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
That's actually the only viable option since there are apps that expect NTFS. We can't require users to change the fs type depending on which app they want to run.
Alexandre Julliard wrote:
Remco remco47@gmail.com writes:
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson
chris.kcat@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type
Why not make the default what the filesystem actually is?
Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
That's actually the only viable option since there are apps that expect NTFS. We can't require users to change the fs type depending on which app they want to run.
I belive that having an option to specify fs type is still required as well because on Windows you are able to create FAT16, FAT32 and NTFS partitions that results in different behavior and functionality. Those behaviors could depend on the fs type setting.
Kornél
2009/4/6 Kornél Pál kornelpal@gmail.com:
Alexandre Julliard wrote:
Remco remco47@gmail.com writes:
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type
Why not make the default what the filesystem actually is?
Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
That's actually the only viable option since there are apps that expect NTFS. We can't require users to change the fs type depending on which app they want to run.
I belive that having an option to specify fs type is still required as well because on Windows you are able to create FAT16, FAT32 and NTFS partitions that results in different behavior and functionality. Those behaviors could depend on the fs type setting.
Implementing NTFS-specific features in Wine would also fix it (though it may not be possible, let alone easy). Then the default FS type could switch back to NTFS instead of unixfs.
On Mon, Apr 6, 2009 at 5:15 AM, Alexandre Julliard julliard@winehq.org wrote:
... since there are apps that expect NTFS.
Just for the record, what do those apps do if you install them in Windows on a non-NTFS drive?
2009/4/6 Chris Robinson chris.kcat@gmail.com:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type (separate from disk type, as is suggested in Comment #7 on 17938). It shouldn't be important for floppies or even CD-ROMs, but the options could be:
- Default (autodetect, fall-back to unixfs)
- FAT12 (floppies)
- FAT16
- FAT32
- NTFS (probably don't need different versions on NTFS)
Possibly restrict these to CDROM type:
- ISO9660
- UDF
Unless someone can come up with a better default than unixfs :)
Why not make the default what the filesystem actually is? Eg. if the FS is FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report unixfs; etc. The registry/winecfg can then be used to override the per-drive type if it causes problems with certain apps.
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given directory is on (noting that wine's "drives" are not even mounted partitions). Expert parsing of /etc/mtab would indicate it on Linux systems (and BSD?) but Solaris has a violently different mtab system.
2009/4/6 Remco remco47@gmail.com:
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.kcat@gmail.com wrote: Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
This doesn't sound trivial, if it's possible at all ;)
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given directory is on (noting that wine's "drives" are not even mounted partitions). Expert parsing of /etc/mtab would indicate it on Linux systems (and BSD?) but Solaris has a violently different mtab system.
HAL shows the information pretty well. It shows the block device, it's mount point, and it's fstype. AFAIK, Wine already uses it to determine the available CD/floppy drives to use.
2009/4/6 Chris Robinson chris.kcat@gmail.com:
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given directory is on (noting that wine's "drives" are not even mounted partitions). Expert parsing of /etc/mtab would indicate it on Linux systems (and BSD?) but Solaris has a violently different mtab system.
HAL shows the information pretty well. It shows the block device, it's mount point, and it's fstype. AFAIK, Wine already uses it to determine the available CD/floppy drives to use.
That might be fine for mount points and mountable devices, but how could you accurately determine the filesystem type for an arbitrary directory like $HOME/.wine/drive_c?
On Sun, Apr 5, 2009 at 8:45 PM, Ben Klein shacklein@gmail.com wrote:
2009/4/6 Chris Robinson chris.kcat@gmail.com:
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given directory is on (noting that wine's "drives" are not even mounted partitions). Expert parsing of /etc/mtab would indicate it on Linux systems (and BSD?) but Solaris has a violently different mtab system.
HAL shows the information pretty well. It shows the block device, it's mount point, and it's fstype. AFAIK, Wine already uses it to determine the available CD/floppy drives to use.
That might be fine for mount points and mountable devices, but how could you accurately determine the filesystem type for an arbitrary directory like $HOME/.wine/drive_c?
Like was already said, default to UNIXFS if unknown. The important thing is that the OPTION be available to change the FS type for apps that need it.
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how could you accurately determine the filesystem type for an arbitrary directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME -> /home/<user>), resolve all symlinks, then see which active mount points that falls into. The mount point with the longest name would then be the mount point/partition to use. Eg:
Drive path for C: $HOME/.wine/dosdrives/c: -> /home/user/.wine/dosdrives/c: -> /home/user/.wine/drive_c
Available fs mount points: / -> /dev/sda3 /home -> /dev/sda4 /boot -> /dev/sda1 /mnt/cdrom -> /dev/hda1
Matching mount points that /home/user/.wine/drive_c exists in and are active: / /home
Mount point with the longest name: /home
Thus, C: is on /home, which is /dev/sda4.
2009/4/6 Chris Robinson chris.kcat@gmail.com:
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how could you accurately determine the filesystem type for an arbitrary directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME -> /home/<user>), resolve all symlinks, then see which active mount points that falls into. The mount point with the longest name would then be the mount point/partition to use. Eg:
Drive path for C: $HOME/.wine/dosdrives/c: -> /home/user/.wine/dosdrives/c: -> /home/user/.wine/drive_c
Available fs mount points: / -> /dev/sda3 /home -> /dev/sda4 /boot -> /dev/sda1 /mnt/cdrom -> /dev/hda1
Matching mount points that /home/user/.wine/drive_c exists in and are active: / /home
Mount point with the longest name: /home
Thus, C: is on /home, which is /dev/sda4.
Easier said than done. Care to write and submit a patch? :)
Ben Klein wrote:
2009/4/6 Chris Robinson chris.kcat@gmail.com:
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how could you accurately determine the filesystem type for an arbitrary directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME -> /home/<user>), resolve all symlinks, then see which active mount points that falls into. The mount point with the longest name would then be the mount point/partition to use. Eg:
Drive path for C: $HOME/.wine/dosdrives/c: -> /home/user/.wine/dosdrives/c: -> /home/user/.wine/drive_c
Available fs mount points: / -> /dev/sda3 /home -> /dev/sda4 /boot -> /dev/sda1 /mnt/cdrom -> /dev/hda1
Matching mount points that /home/user/.wine/drive_c exists in and are active: / /home
Mount point with the longest name: /home
Thus, C: is on /home, which is /dev/sda4.
Easier said than done. Care to write and submit a patch? :)
Well, a 'df -T /home/user/.wine/drive_c' shows you the mountpoint and filesystem type (on Linux that is, not sure if '-T' is available in *nix).
Even 'df -T /home/user/.wine/dosdevices/c:' will give you the correct mountpoint and filesystem type.
Paul Vriens wrote:
Even 'df -T /home/user/.wine/dosdevices/c:' will give you the correct mountpoint and filesystem type.
df -T is not portable (tested - does not work on Solaris).
IMO Autodetection code is too much overhead here, given the Wine multi-platform support.
Providing unixfs as default and drop-down box for user override seems a bit more viable path.
Cheers Hark
On Sun, 5 Apr 2009, Chris Robinson wrote: [...]
Available fs mount points: / -> /dev/sda3 /home -> /dev/sda4 /boot -> /dev/sda1 /mnt/cdrom -> /dev/hda1
Matching mount points that /home/user/.wine/drive_c exists in and are active: / /home
Mount point with the longest name: /home
Thus, C: is on /home, which is /dev/sda4.
So what about the z: drive which points to /? Do you report it as /dev/sda3 although z:\home is on a different filesystem of a potentially different type?
Now while I'm arguing, it's possible that it can happen on Windows too through reparse points (I believe that's how they're called) and then we should be able to report it to the Windows application using the same mechanism.
"Chris Robinson" chris.kcat@gmail.com wrote:
Why not make the default what the filesystem actually is? Eg. if the FS is FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report unixfs; etc. The registry/winecfg can then be used to override the per-drive type if it causes problems with certain apps.
The problem with NTFS is that Wine won't support its ioctls in any case, and that's the real reason why its was changed to unixfs.
On Sun, Apr 5, 2009 at 7:35 PM, Ben Klein shacklein@gmail.com wrote:
If I interpret it correctly, the user reporting bug 17938 is trying to use a native NTFS filesystem with Wine, which we already know is a bad idea :)
No. The problem is that we _used_ to have NTFS reported as the default file system, but now we use UNIXFS. The user didn't name their file system, but presumably, it's ext3/jfs/xfs/not NTFS.
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files), then we might just have to make this configurable, possible on a per-app basis.
That's exactly the issue at hand ;-).
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type (separate from disk type, as is suggested in Comment #7 on 17938). It shouldn't be important for floppies or even CD-ROMs, but the options could be:
- Default (autodetect, fall-back to unixfs)
- FAT12 (floppies)
- FAT16
- FAT32
- NTFS (probably don't need different versions on NTFS)
Possibly restrict these to CDROM type:
- ISO9660
- UDF
Unless someone can come up with a better default than unixfs :)
My idea exactly.
Ben Klein wrote:
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files), then we might just have to make this configurable, possible on a per-app basis.
My suggestion is a drop-down box in the "Advanced" tab of "Drives" to control filesystem type (separate from disk type, as is suggested in Comment #7 on 17938). It shouldn't be important for floppies or even CD-ROMs, but the options could be:
- Default (autodetect, fall-back to unixfs)
- FAT12 (floppies)
- FAT16
- FAT32
- NTFS (probably don't need different versions on NTFS)
Possibly restrict these to CDROM type:
- ISO9660
- UDF
Unless someone can come up with a better default than unixfs :)
How about having the per-application entry in registry to simulate the fs type for? It's in the same spirit like already implemented simulation of Windows version per application.
This way it won't affect 'drive' settings, but only the information passed to that certain application.
---- Hark
On Mon, 6 Apr 2009, Ben Klein wrote: [...]
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files),
Then the application is buggy: NTFS is not the only filesystem that supports >2GB files on Windows. Even if they are not very common, there are at leastt two drivers to use Ext2 filesystems on Windows (Ext2Fsd, Ext2 IFS), both of which support >2GB files. Besides if Microsoft ever changes the filesystem again, it will most certainly support >2GB files and the application will get it wrong again.
So instead the application should only split files when it detects either Fat16 or Fat32.
Maybe the DVD Shrink author would agree to do this change if asked?
Ext2fsd: http://ext2fsd.sourceforge.net/ Ext2 IFS: http://www.fs-driver.org/
On Thu, 16 Apr 2009 09:19:05 +0200 (CEST) Francois Gouget fgouget@free.fr wrote:
Maybe the DVD Shrink author would agree to do this change if asked?
Development of DVD Shrink was halted in 2005 due to DMCA issues.
On Thu, Apr 16, 2009 at 2:19 AM, Francois Gouget fgouget@free.fr wrote:
On Mon, 6 Apr 2009, Ben Klein wrote: [...]
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files),
The problem is not just DVD Shrink/files > 2GB. There are several other applications that expect to see FAT32 or NTFS (see http://bugs.winehq.org/show_bug.cgi?id=17980).
Maybe the DVD Shrink author would agree to do this change if asked?
DVD Shrink is abandonware.
2009/4/16 Francois Gouget fgouget@free.fr:
On Mon, 6 Apr 2009, Ben Klein wrote:
But his bug raises an interesting issue. If an application has sanity checks on FAT32 vs NTFS (e.g., I need a 4GB file ... I've detected no NTFS therefore it's FAT32 which doesn't support more than 2GB files),
Then the application is buggy: NTFS is not the only filesystem that supports >2GB files on Windows. Even if they are not very common, there are at leastt two drivers to use Ext2 filesystems on Windows (Ext2Fsd, Ext2 IFS), both of which support >2GB files. Besides if Microsoft ever changes the filesystem again, it will most certainly support >2GB files and the application will get it wrong again.
Usage of file systems other than FAT32 or NTFS on Windows is somewhere below negligible.
(Unless USB sticks really do go UDF to avoid a FAT tax, or something.)
So apps doing this may theoretically be sloppy programming, but in practice they'd pretty much always get the right answer on Windows.
- d.
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Vitaliy closed this bug, saying it's an application bug that it depends on seeing NTFS file system type for certian program features. I don't think it should be a WONTFIX, as the only reason that change was introduced was to enable _another_ program to install successfully.
Is there any reason we can't allow the reported file system to be changed? I'm sure there are other applications that test for it and change their behavior according to the file system type. A quick google search shows at least one application that does (http://boards2.sega.com/sega_board/viewtopic.php?p=2669064&sid=449f531c5...). That install will likely now fail in Wine, because of this behavior.
So what you decided? Every person proposed their own solution with neither one of them really solving the problem.
- Implement missing functionality - will most likely be nearly impossible without driver support for special features. Or have to be emulated by Wine (then why not for any other FS?) - Making FS settable via winecfg/registry - a workaround which again doesn't solve anything. Highly app specific. No way for user to know app needs particular FS - FS auto-detection - doesn't solve anything (see above)
Vitaliy.
2009/4/7 Vitaliy Margolen wine-devel@kievinfo.com:
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Vitaliy closed this bug, saying it's an application bug that it depends on seeing NTFS file system type for certian program features. I don't think it should be a WONTFIX, as the only reason that change was introduced was to enable _another_ program to install successfully.
Is there any reason we can't allow the reported file system to be changed? I'm sure there are other applications that test for it and change their behavior according to the file system type. A quick google search shows at least one application that does (http://boards2.sega.com/sega_board/viewtopic.php?p=2669064&sid=449f531c5...). That install will likely now fail in Wine, because of this behavior.
So what you decided? Every person proposed their own solution with neither one of them really solving the problem.
- Implement missing functionality - will most likely be nearly impossible
without driver support for special features. Or have to be emulated by Wine (then why not for any other FS?)
If it is possible, this will fix it. (I'm unsure as to what's missing, but someone mentioned failing ioctls before.) See what AJ said:
2009/4/6 Alexandre Julliard julliard@winehq.org:
Another option is to actually implement the NTFS-specific features of Windows, and call it NTFS.
That's actually the only viable option since there are apps that expect NTFS. We can't require users to change the fs type depending on which app they want to run.
2009/4/7 Vitaliy Margolen wine-devel@kievinfo.com:
- Making FS settable via winecfg/registry - a workaround which again doesn't
solve anything. Highly app specific. No way for user to know app needs particular FS
Same argument could be made for any setting in winecfg/UsefulRegistryKeys. It tends to be trial-and-error, with results posted on appdb or bugzilla (where appropriate). E.g., app XYZ only works if reported Windows version is set to nt40, etc.
A better reason why user-configured FS should not be available is because it hides real bugs.
On Tuesday 07 April 2009 04:21:37 Vitaliy Margolen wrote:
- Implement missing functionality - will most likely be nearly impossible
without driver support for special features. Or have to be emulated by Wine (then why not for any other FS?)
We can probably get away with 80% of the apps only using 20% of the features, as usual. I guess that apps are mostly interested in ACLs, which could be mapped to POSIX acls, stored in file attributes or some database or simply faked. Samba does this, I don't see why we couldn't.
Cheers, Kai
-
Alexandre Julliard -
Austin English -
Ben Klein -
Chris Robinson -
David Gerard -
Dmitry Timoshkov -
Francois Gouget -
James McKenzie -
Kai Blin -
Kornél Pál -
Paul Vriens -
Remco -
Rosanne DiMesio -
Sparr -
Vit Hrachovy -
Vitaliy Margolen