Justin Erenkrantz wrote:
> On 2/7/06, Julian Foad <julianfoad@btopenworld.com> wrote:
>
>>It may be true that there is no accurate way to determine what FS "you are on"
>>(more precisely, on which a particular file is stored). It is wrong to imply
>>that the WC can't cope. There are all sorts of ideas for what the WC could do.
>
> No. You have no way to know how the underlying file system will
> handle with these conflicting/incompatible names.
Maybe not, at least not in advance of trying the operation. But maybe that's
not exactly what we need to know.
I'm trying to approach this in a way that first asks whether it is logically
possible to solve the problem, and then helps others to explore any possible
solutions in the hope of finding a practical (neat, efficient) solution.
[...]
> Windows just trims off the dots silently.
[...]
> I don't think you can even know that the file wasn't handled correctly.
As for Windows removing dots, I would find it extremely hard to believe that
Windows doesn't provide any way to discover the new name of a file that you
write, or the actual name of a file that you open.
Maybe this is much more difficult than we would wish, or irregular, or
incomplete, or ugly. Maybe even impossible. But that just means it will take
a little longer :-)
It seems to me that that the feasibility of solving this class of problems in a
friendly and automatic way depends on the ability to detect whether a
particular filename:
* can be written as-is, or
* cannot be written, or
* will get automatically modified (to what?)
Ideally we would have an API that answers that question for a particular
pathname (perhaps in the course of actually creating or opening the file)
efficiently on all platforms.
Let's (anyone who's interested) start by trying to solve one small piece of the
problem at a time, and let's not let worries about "performance" prevent us
from exploring possible solutions.
For a start, I'm sure this issue of the file with trailing dots being reported
by Subversion as "missing" could be solved. The function that writes the file
could, immediately after writing it, use the same method to check whether it
exists that it is going to use later on, and at that early stage return failure
if it can't recognise it. Yes, that's ultra-crude, but if it works that's a
step forward, proof that it's logically possible. Then the problem is reduced
to investigating other techniques to see whether the detection can be improved
enough to be acceptable in mainstream use. Then the WC could handle the
situation in some acceptable way.
> On Mac OS X hsfs, the stat() for the case-insensitive
> names will success return for all variations. -- justin
That makes sense for the behaviour of "stat", but I bet there is some way,
however ugly, to find the actual version of the name as it would be displayed.
I have long had an interest in the case-insensitivity problem, but since I
stopped using Windows it's become only an academic interest with no motivation
to do anything practical towards it. I think the same techniques that could
overcome the dots problem could also be useful for managing the case problem.
In particular, because it is difficult to know on what filesystem a particular
path exists, I think the technique for handling filenames that might be
case-insensitive must involve an API that operates or answers questions on a
particular path, such as "is P1 the same path as P2" (resolving relative
directories, symlinks, case-insensitivity, etc., as appropriate for that
particular path).
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 8 01:58:07 2006