On Tue, Jan 24, 2012 at 1:18 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
[ ... ]
> I'd like to note though that #4023 is also potentially an issue for
> svn < 1.7 (pre-wcng). At least if you're thinking about
> non-commandline usage. As of #3865, one can now also run into this
> situation with the commandline client, because you're now able to
> successfully invoke 'svn rm foo' while foo is missing and unversioned
> FOO is in the way. But if you're talking directly to the client layer,
> it's easy to pass 'foo', and the current code will then happily remove
> foo from wc.db, and FOO from disk. There is no need for any of my
> "fixes" to do that.
Just to confirm this point: I've been able to reproduce #4023 (or a
variation thereof) with TortoiseSVN 1.6:
- Add 'foo' as a versioned file. Commit.
- Delete 'foo' from filesystem (non-svn delete).
- Create new file 'FOO'.
- Right-click and TSVN -> Add
- You get a warning that another item which only differs in case
already exists. Click 'Add the item anyway'.
- Right-click in the directory, and choose 'Check for modifications'
(i.e. 'svn status')
- Now you can see foo as missing, and FOO as added.
- Right-click foo, and choose Delete. Now FOO is deleted from disk.
I'll try to update the issue later tonight, to remove the 'since 1.7'
denomination, and rephrase it independently of the use of 'svn' (the
commandline executable). It's a libsvn_client or libsvn_wc issue.
So my conclusion is: libsvn_client / libsvn_wc shouldn't assume that
they always receive a truepath-canoncalized local path. They can
always receive a path that's a valid wc-item, but is not present on
disk and is case-shadowed by another item on disk [1]. This means that
they should be very careful when calling filesystem API's where they
don't care whether the exact same file exists or not (in casu:
'delete'): better to check whether the file (with the same exact case)
exists, before calling delete, to avoid accidentally deleting the
wrong file.
[1] The fact that the svn <1.7 commandline client cannot throw such
case-shadowed targets at the client layer is just a very thin layer of
protection, and IMHO a shortcoming which was rectified with #3865.
P.S.: It would be interesting to know if #4023 is also an issue on OSX
(with case-insensitive filesystem). I guess it is, but I don't have
such a system, so if anyone could try this ...
--
Johan
Received on 2012-01-25 01:48:37 CET