http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #22 from André H. nerv@dawncrow.de 2012-06-20 13:03:39 CDT --- (In reply to comment #20)
(In reply to comment #19)
...
- do we really want to advertise junction point support for every fs? [1]
No, the way I currently have it we would only advertise support if the filesystem is NOT one of the following: ISO9660, UDF, FAT16, or FAT32. I looked rather extensively at a way to test for symlink support and I've so far been unable to find a way to do this without actually trying to create a link.
OK
...
- test special cases not only create, read, delete per ioctl, but use e.g.
DeleteFile() to delete the link and see what happens, delete the target and see what happens,
I've added several more test cases and spread them out throughout the patches so that each case goes with the appropriate code. This actually exposed a problem that currently exists in deleting a symlink that's a folder, at this time Wine fails to handle that properly (fix in patch 5).
That's a problem for patch 1, there you can't clean up the test... if RemoveDirectoryW(path); in patch 1 also removes the containing symlink then that's ok, otherwise i'd suggest to do: * patch 1: creation without tests * patch 2: deleting with tests for creation and deleting * patch 3: reading with tests ...
minor issues: for your tests please add ok() calls after e.g. CreateDirectoryW so it's easier to why something fails, in case that happens. intendation problems in tests of patch 1,2 and 5 like e.g. at CreateFileW in patch 1
...
- all these skip() makes me nervous, maybe some more win_skip() when
appropriate. Further i think they can be reduced.
Please see if this version looks more acceptable.
Yes
(In reply to comment #21)
(In reply to comment #20)
... Thanks! I think the only thing that's not covered now is symlinks (Vista+ feature), but I figured that I should start with junction points first.
After testing with the .NET 2.0 installer, I realized something that I'd appreciate some feedback about: the way I've done this so far creates an absolute path link. For example: /home/ehoover/.wine/dosdevices/c:/windows/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a links to: /home/ehoover/.wine/dosdevices/c:/windows/winsxs/x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790
It seems to me that this technique has the disadvantage that if users relocate their Wine directory that these links would break. So, do you guys think I should replace "/home/ehoover/.wine/dosdevices/" with the appropriate number of up directory references (../../../../../ in this case).
That diserves an own patch at the end of the patchset i'd say.