[Bug 12401] Support junction points, i.e. DeviceIoCtl(FSCTL_SET_REPARSE_POINT/FSCTL_GET_REPARSE_POINT)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=12401

--- Comment #22 from André H. <nerv at 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.