I'm not sure why you beeze over novells netdrive, a simple google finds
alternative downloads (as novell's site has been broken for a while),
and I've had clients use it without any issues. It sounds like you
actually expect software from microsoft to work as advertised.. most of
us gave that up years ago.. ;)
>I'm casting a wide net here, looking for a solution to a problem many
>users are going to have with Subversion's autoversioning features,
>when 1.2 comes out.
>Autoversioning is the feature whereby generic DAV clients (say,
>Windows WebFolders) can drag files to and from a DAV share that is
>backed by a Subversion repository. Dragging to the share results in a
>commit, dragging from it works like a checkout.
>Autoversioning is a Great Thing. It will expose many new users to
>Subversion, in a simple and painless way, and make Subversion servers
>that much more attractive to admins.
>However, there is a fly in the ointment, a dragon in the meadow, a
>shrubbery in the suitcase:
>Transparent DAV filesharing doesn't work smoothly in Windows XP.
>A detailed description of the problem is below. Anyone who knows
>reliable workarounds, or has more information, please follow up to
>this post. And let's please not get into "It's Microsoft's fault for
>breaking an access syntax". That may be so, but the point here is to
>find a solution. Recalling all copies of XP is not realistic :-).
>Under Windows 98 and Windows 2000, accessing a DAV server via
>WebFolders was simple: you typed in the URL, and everything worked.
>Under XP, the situation changed. Microsoft decided that when the user
>types a URL, what they really meant was a UNC path (something like
>So WebFolders converts the URL to some analogous UNC path, then goes
>off looking for that resource on the LAN. Of course, if the user
>really meant a URL -- i.e, a true DAV server -- they're out of luck.
>It doesn't matter whether the server is IIS or mod_dav under Apache,
>because the server never even sees the request!
>(Of course, if it's IIS, it might be serving the same resources on the
>LAN via UNC paths, making it *look* like "IIS works, Apache doesn't".
>But that's not really what's going on. No DAV server works, because
>the client never even reaches the DAV server. If the IIS server were
>remote and/or not accessible via UNC, it wouldn't work either.)
>There are workarounds for this problem, but they apparently differ
>depending on XP servicepack combinations. We don't yet have a matrix
>describing what workarounds work with what exact kinds of XP.
>One workaround is to include a port number in the URL is enough to
>suppress to the URL->UNC translation step, e.g.,
>In some flavors of XP, this is enough to suppress the URL->UNC
>conversion and reach the DAV code buried in the bowels of WebFolders.
>However, other flavors of XP will not be fooled, and will still
>convert it to UNC.
>Ben Collins-Sussman recalls hearing about another workaround, reported
>to work on XP boxes where the port-number workaround didn't work, in
>which one enters the URL in IE's File->Open box and gains access that
>way. I haven't been able to dig up that URL yet, and I don't know
>anything about the reliability/portability of that workaround.
>The most reliable workaround currently known is to purchase WebDrive
>($40 out of the box, site licenses also available), which simply takes
>over from WebFolders and honors the DAV URLs the user enters. There's
>also a free-as-in-beer product from Novell called NetDrive that does
>the same thing, but apparently not as reliably. These workarounds
>would presumably cover most or all XP variants, but of course
>installing yet more new software to get autoversioning working would
>cause a lot of grumbling.
>We don't yet know whether this problem can be worked around in every
>variant of XP that our users might run. Maybe there is a single
>workaround that will solve this everywhere; or maybe each variant has
>a workaround, but not the same workaround as other variants. It is
>also possible that some variants simply have no workaround. Gulp.
>So: if anyone knows something not mentioned above, please speak up!
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Apr 23 01:43:27 2005