> Doh123, how is running a program off an NTFS partition asking for trouble? Ntfsprogs seems to handle it just fine. I know that NTFS doesn't let you mark a file as executable, and that the filesystem is susceptible to fragmentation, but you should just be able to tell it to run rather than display and be good. It shouldn't cause destruction. I think there might even be an NTFS defrag tool for Linux, I'd have to check. > Really NTFS is fairly good on fragmentation resistance as long as drive remains under 90 percent full. And shake defrag will work okish on it. I have had to use shake defrag from Linux on a ntfs drive that was that badly fragmented that windows defrag tools would not even attempt. But executable bit is not the only file system part Ntfsprogs is missing. There is a serous difference in mmap handling compared to ext2 ext3 or ext4 from the ntfs3g driver. These differences do cause failures in applications when on ntfs with wine that don't happen when on ext2 ext3 or ext4. So for us doing support we want tested on ext filesystems so we know if the issue you are seeing is ntfs3g issue or wine with every file-system. ntfsprogs still lacks a 100 percent working fsck to fix up in case of power loss or other case of lose of operation. So after power loss booting into windows can be required to restore access to the ntfs drive. Ok what cause a power loss like event. Wine finding a video card driver defect so crashing the kernel. So not a wise combination. Ntfs3g what you have to use for writing support also has a high cpu load than using a native ext3/4 as a loop back on ntfs3g. (Yes I know that is wrong but its the way the numbers work out). Really running loop back on top of another file-system should work out slower but this is one of these odd cases. Using NTFS is also not good to keep the separation between windows installed executable and wine installed executable. This can turn into major problems for wine and windows. Windows loading up an application installed by wine can completely destroy windows at times. Yes we don't like getting into trouble for destroying copies of windows. Also applications installed in windows and copied to wine can also have issues due to missing register entries and other things. Next issue is fools. Who here that wine works on NTFS so points the wine c drive to there windows c drive then wonder why next boot of windows nothing works. And the most annoying of all(we have this with Linux a little). Is that wine place holder executable get detected and deleted by lots of Commercial anti-virus software so causing malfunctions you will not otherwise see. There are particular commercial anti-viruses that run under Linux that should not be used with wine as well. But there are options under the commerical anti-viruses for Linux to exude wine directories from being scanned by them and to use something like clamav to cover the areas that are touchy. Not so simple in a Windows environment to have particular directories monitored and scanned by different anti-virus products. So this leads to major problems due to a lack of flexibility on the windows side. Secuirty you don't want to leave directories unmonitored. Simply for all sanity. Its better to act like wine does not work on NTFS at all. That way anyone running it on NTFS is doing so at there own risk can cannot be recommend it as working so we don't get more complaints from the issues that will crop up in time.
