http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #22 from André H. <nerv(a)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.
--
Configure bugmail:
http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.