Boost logo

Boost :

Subject: Re: [boost] [filesystem] proposal: treat reparse files as regular files
From: Paul Harris (harris.pc_at_[hidden])
Date: 2015-07-29 23:54:20


On 30 July 2015 at 11:33, Gavin Lambert <gavinl_at_[hidden]> wrote:

> On 30/07/2015 14:49, Paul Harris wrote:
>
>> On 29 July 2015 at 14:09, Gavin Lambert <gavinl_at_[hidden]> wrote:
>>
>> I'm not sure if it's current, but
>>>
>>> http://blogs.technet.com/b/filecab/archive/2013/02/14/dfsr-reparse-point-support-or-avoiding-schr-246-dinger-s-file.aspx
>>> seems to suggest the following behaviour as reasonable:
>>>
>>> - treating IO_REPARSE_TAG_MOUNT_POINT as directory symlinks
>>> - treating IO_REPARSE_TAG_SYMLINK as symlinks
>>> - treating IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_SIS, and
>>> IO_REPARSE_TAG_HSM as regular files
>>> - treating any other tag as something to be ignored (in most cases)
>>>
>>>
>>> I believe the last point is wrong in our context. That blog is talking
>> about DFS Replication, which is a very special case for reading files.
>> The
>> fallback ("dehydrating and rehydrating files") is something they'd rather
>> not do because it would be unpacking files out of 3rd party archival
>> areas. They'd rather not read and copy content if they can avoid it.
>>
> [...]
>
>> So I would have written that last point as:
>> - treating any other tag as a regular file
>>
>
> If you have a look at the very next paragraph in the quoted message,
> that's what I said. :)
>
> (The part you quoted was repeating what the blog said, not as a
> recommendation for Boost library behaviour.)
>
>
Sorry, you mean this bit :

There was also a note that you can use IsReparseTagNameSurrogate to
> determine if a given reparse point tag is a surrogate (some kind of link)
> or not (treat like regular file). That might be the best option, if it's
> consistent -- and at least for the official MS tags it seems to be;
> MOUNT_POINT and SYMLINK are surrogates and the other types are not.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk