http://bugs.winehq.org/show_bug.cgi?id=14914
--- Comment #28 from Nate natrik@gmail.com 2009-11-01 17:05:34 --- THE NEXT STEP, it seems clear to me, is for someone interested and capable to write and submit code to this page.
The code should produce a sequential, and (reasonably) contiguous file, that is with bytes written mostly in order (with respect to disk blocks) within the file's allocated space) in a current windows version on native windows filesystem(s).
The same code should produce a badly fragmented file (maybe initially allocated sparsely?) with bytes written completely out of order (with respect to allocated disk blocks) within the file's allocated space, when run through current Wine under a current Linux on native Linux filesystem(s).
PERHAPS the code would allocate rather big files, and write randomly to them in the same manner as uTorrent (which is incidentally not open source).
I really wish I could write this code myself. I would already be enjoying myself with the challenge. I think I understand the concepts well enough, but not the programming.
...
While I do understand that the ROOT CAUSE is the lack of some "no_sparse" somewhere IN LINUX, I also understand that, in this case, current Wine code does not result in Windows-behavior end-result allocation (with respect to the order of data on the disk). Furthermore, I also understand that, lacking a direct "not-sparse" allocation option in Linux, attempts to modify Wine for this case could really screw up other programs' performance. (And therefore would probably be best implemented as a runtime switch, like --no-sparse or --explicit-sparse).
There seems no doubt by anyone here that it is a challenging issue from an algorithmic perspective to align actual results with expected results, but it clearly can be done, and I see no reason it can't be done in Wine. After all, if program function and system performance inconsistencies between Wine and Windows is not "buggy" then surely I am misinformed on the purpose of Wine.