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

Re: svn hotcopy incremental overwrites existing revisions in backup

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 16 May 2017 21:40:40 +0200

On 16.05.2017 21:28, Stefan Sperling wrote:
> On Tue, May 16, 2017 at 12:02:38PM -0700, lumi wrote:
>> Isn't it a mistake in method of getting file size on deduplicated volume?
> Subversion asks APR (a portability library) for the filesize.
> APR does something to find that size. Subversion uses the value reported
> by APR, and Subversion does not care about how APR figured it out.
>
> So if there is a problem with how the size is determined on Windows with
> NTFS de-duplication enabled, then this problem is probably located in APR
> and should be fixed there. The APR project is at https://apr.apache.org
>
> That said, if you know of a way to find the correct size with the win32 API
> we could probably patch Subversion to bypass APR for this specific case.
> But APR would have to be fixed anyway.

I suspect the ReparsePoint attribute on the file is what actually makes
APR hiccup. A "reparse point" is distantly related to a unix symlink ...
it tells the file-system path resolver to restart with a different path.
I bet that APR reports is the size of the reparse-point record instead
of the size of the target file, but when we open the file we get the
actual file contents.

-- Brane
Received on 2017-05-16 21:40:45 CEST

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

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