Re: [boost] [filesystem] proposal: treat reparse files as regular files

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

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.

This is so specific that they probably shouldn't be using boost libraries
to do this work.

3rd party companies (like McAfee, Symantec) can request a unique reparse
tag for their custom server software,
When the file is read, the Server uses the reparse tag ID to match up with
the required 3rd party driver to handle the read/write.
For example, Symantec Enterprise Vault v10 has Reparse Tag Value 0x00000010
(observed on server in the wild).

If you like, I can send a screenshot of this particular file, taken on a
Windows 7 client computer, looking at K: (a network share of a Windows
server).

This allows 3rd party companies to make their own fancy cluster/archival
storage solutions.
The only way I can read this particular file is through the first
filename...... there is no symlink to follow.  So its not a symlink, there
is no second filename to look at.
In this particular case, the files are archived if not read for X days.
When you first open the file, Symantec replaces the reparse-point file with
the REAL file, and things continue as normal from there.  So, similar
purpose to a dedup file, but different implementation.

So I would have written that last point as:
- treating any other tag as a regular file

Because in this case, the Server Admin that I talk to want to install
whatever software they like on the server, and for client software to just
read the files.
They use this software to reduce the storage usage.  Thats all.

cheers,
Paul