Re: NTFS filesystem features - WONTFIX?
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/ -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Re: NTFS filesystem features - WONTFIX?
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. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: NTFS filesystem features - WONTFIX?
On Thu, 16 Apr 2009 09:19:05 +0200 (CEST) Francois Gouget fgou...@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. -- Rosanne DiMesio dime...@earthlink.net
Re: NTFS filesystem features - WONTFIX?
On Thu, Apr 16, 2009 at 2:19 AM, Francois Gouget fgou...@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. -- -Austin
Re: NTFS filesystem features - WONTFIX?
2009/4/16 Francois Gouget fgou...@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.
Re: NTFS filesystem features - WONTFIX?
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 -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: NTFS filesystem features - WONTFIX?
On Tue, Apr 7, 2009 at 1:49 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Kai Blin kai.b...@gmail.com wrote on April 7th: Subject: Re: NTFS filesystem features - WONTFIX? 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. Can we use Samba code in Wine to make this a reality? Samba is GPL3 licensed, so not without relicensing. -- -Austin
Re: NTFS filesystem features - WONTFIX?
Kai Blin kai.b...@gmail.com wrote on April 7th: Subject: Re: NTFS filesystem features - WONTFIX? 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. Can we use Samba code in Wine to make this a reality? James McKenzie
Re: NTFS filesystem features - WONTFIX?
On Tue, Apr 7, 2009 at 2:01 PM, Austin English austinengl...@gmail.comwrote: On Tue, Apr 7, 2009 at 1:49 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Kai Blin kai.b...@gmail.com wrote on April 7th: Subject: Re: NTFS filesystem features - WONTFIX? 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. Can we use Samba code in Wine to make this a reality? Samba is GPL3 licensed, so not without relicensing. -- -Austin There were older releases of Samba 3 that were not GPLv3 licensed, couldn't that code be used... Wait, I just realized, it would still have to be relicensed to LGPLv2.1, though they would probably have less inclination to do so for the GPLv3 releases over the GPLv2 ones.
Re: NTFS filesystem features - WONTFIX?
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
Re: NTFS filesystem features - WONTFIX?
Ben Klein wrote: 2009/4/6 Chris Robinson chris.k...@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. -- Cheers, Paul.
Re: NTFS filesystem features - WONTFIX?
Alexandre Julliard wrote: Remco remc...@gmail.com writes: On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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
Re: NTFS filesystem features - WONTFIX?
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
Re: NTFS filesystem features - WONTFIX?
Remco remc...@gmail.com writes: On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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 julli...@winehq.org
Re: NTFS filesystem features - WONTFIX?
2009/4/6 Kornél Pál kornel...@gmail.com: Alexandre Julliard wrote: Remco remc...@gmail.com writes: On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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.
Re: NTFS filesystem features - WONTFIX?
On Mon, Apr 6, 2009 at 5:15 AM, Alexandre Julliard julli...@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?
Re: NTFS filesystem features - WONTFIX?
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=2669064sid=449f531c594a92fd2470e9c5a5f10b4f). 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.
Re: NTFS filesystem features - WONTFIX?
2009/4/7 Vitaliy Margolen wine-de...@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=2669064sid=449f531c594a92fd2470e9c5a5f10b4f). 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 julli...@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-de...@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.
NTFS filesystem features - WONTFIX?
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=2669064sid=449f531c594a92fd2470e9c5a5f10b4f). That install will likely now fail in Wine, because of this behavior. -- -Austin
Re: NTFS filesystem features - WONTFIX?
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
Re: NTFS filesystem features - WONTFIX?
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie jjmckenzi...@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. -- -Austin
Re: NTFS filesystem features - WONTFIX?
2009/4/6 Austin English austinengl...@gmail.com: On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie jjmckenzi...@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 :)
Re: NTFS filesystem features - WONTFIX?
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.
Re: NTFS filesystem features - WONTFIX?
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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
Re: NTFS filesystem features - WONTFIX?
On Sun, Apr 5, 2009 at 7:35 PM, Ben Klein shackl...@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. -- -Austin
Re: NTFS filesystem features - WONTFIX?
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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
Re: NTFS filesystem features - WONTFIX?
2009/4/6 Chris Robinson chris.k...@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 remc...@gmail.com: On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@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 ;)
Re: NTFS filesystem features - WONTFIX?
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.
Re: NTFS filesystem features - WONTFIX?
2009/4/6 Chris Robinson chris.k...@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?
Re: NTFS filesystem features - WONTFIX?
On Sun, Apr 5, 2009 at 8:45 PM, Ben Klein shackl...@gmail.com wrote: 2009/4/6 Chris Robinson chris.k...@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. -- -Austin
Re: NTFS filesystem features - WONTFIX?
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.
Re: NTFS filesystem features - WONTFIX?
2009/4/6 Chris Robinson chris.k...@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? :)
Re: NTFS filesystem features - WONTFIX?
Chris Robinson chris.k...@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. -- Dmitry.
