[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: JavaHL: ClientNotifyCallback reports unexpected kind "file" for symlinks

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 20 May 2015 11:18:50 +0200

On 20.05.2015 08:54, Marc Strapetz wrote:
> On 19.05.2015 16:40, Bert Huijben wrote:
>>
>>
>>> -----Original Message-----
>>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>>> Sent: dinsdag 19 mei 2015 15:59
>>> To: dev_at_subversion.apache.org
>>> Subject: JavaHL: ClientNotifyCallback reports unexpected kind "file"
>>> for
>>> symlinks
>>>
>>> When recursively adding a directory "test" which contains another
>>> directory "sub" and a symlink "sub.link" pointing to "sub", "sub.link"
>>> is reported with kind=file where I would expect to receive
>>> kind=symlink.
>>> The problem can be reproduced by following code snippet, using quite
>>> recent 1.9 binaries:
>>
>> I don't think Subversion uses kind is symlink anywhere in its public
>> api (yet), so this is totally expected.
>>
>> When we build WC-NG for Subversion 1.7 we introduced database support
>> for storing symlinks as their own kind, but we never switched to this
>> storage yet. Currently symlinks are still files with an 'svn:special'
>> property set on them internally, for Subversion repositories.
>>
>> The node kind enum was extended when we moved to a single enum for
>> node kinds, but changing how we report and store symlinks is far from
>> trivial.
>
> Thanks, Bert. I was pretty sure to have seen "symlink" kind reported
> somewhere. Now I think it might just be our own code which uses (or
> checks) for "symlink" ... I'll investigate in more detail.
>
> Either way, from an API user perspective, it would be helpful to
> distinguish between normal files and symlinks, especially because
> symlinks may refer to (local) directories and usually need a different
> treatment. Should I file an RFE in the issue tracker?

We can't report symlinks (e.g., in "svn status") without writing new
versions of a whole bunch of svn_client and other functions. This will
definitely not happen any time soon, especially since there is a trivial
solution: either stat the path (on Unix) or check if it has the
svn:special property set (on any platform).

> Or would this happen implicitly when switching to the planned 1.7 storage?

Which 1.7 storage are we talking about?

-- Brane
Received on 2015-05-20 11:20:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.