Bug: Windows(Vista) mounted NTFS partition not usuable (not regocnized as directory)

On Windows(Vista) it is possible to mount a partition (partition on the
local / build-in drive) as a folder, instead of assigning it a drive letter.

TortoiseSvn does not work (update, log, commit) if you try to use such a
mount point as root directory for your checkout.
"Find modifications" does work

Additionally Tortoise fails to commit (but works for log and update) if
the checkout root is a drive. (such as a partition mounted as "X:")

Testing with the "slik" commandline-client, shows that the command line
client does work.

Example:

In my setup I partitioned the build-in harddisk, making 2 partitions:
partition 1 has the drive-letter C:
partition 2 is mounted as C:\data (C:\data has to be created as empty
folder first, then the partition can be mounted)

If I try to checkout (new checkout) of a repository into C:\data I get:
- A warning which is correct:
   the folder is not empty (because there are some system folders, such
as volume-info and recycle bin).
   I confirm that I still want to continue and this does work
- An error (which I believe to be a bug)
    C:\data' already exists and is not a directory

Similar if I copy (including hidden .svn folders) an existing checked
out repository into C:\data some svn function (such as update, commit or
log) do no longer work (they still work on individual sub directories).

If you try "show log" on a repository copied into such a folder,
tortoise claims "'C:' is not a working copy" => despite executing the
command on "C:\data" (again subfolders in c:\data (that are part of the
checkout) do work

Mounting the folder in additon as drive (X:) and then trying to commit
in X: results in an error that "\" (as folder) is not correct.
This is if you call commit from the context menu of the drive, even if
the file is further down in a directory.
You can commit files in subdirectories, but only if you select commit
fron the popup menu of the subdirectory.

Best Regards
Martin

---
some added info, not sure if it is related:
I checked the attribute returned by FindFirst/FindNext
In Addition to
"FILE_ATTRIBUTE_DIRECTORY 0x0010	The handle that identifies a directory."
for mount-points it returns also
"FILE_ATTRIBUTE_REPARSE_POINT 0x0400 A file or directory that has an 
associated reparse point, or a file that is a symbolic link. "
(descriptions from MSDN)
I also tested the result for a windows-shortcut (.lnk; and a shortcut, 
does not include FILE_ATTRIBUTE_REPARSE_POINT.
A shortcut (to a directory) simply was marked as a directory, and for 
some reason was also given the FILE_ATTRIBUTE_READONLY attribute.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2460616
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].