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

Subject: Re: [boost] [filesystem] proposal: treat reparse files as regular files
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-07-29 19:17:26

On 29/07/2015 22:59, Niall Douglas quoth:
> Unfortunately getting FileReparsePointInformation returns just a
> single record which is the reparse point for the directory handle
> being enumerated. It doesn't return reparse tags for directory
> contents.

Ah, true.  I missed that part.  Seems kinda annoying they made that 
different from all the other information classes.

> I'm thinking that as reparse points are really just an overload on
> EA, maybe the returned EaSize field is magically set to the reparse
> tag when attributes specify it's a reparse point file? I'd have to
> experiment to find out. I can't see any other obvious field which
> would return the reparse tag.
>
> EDIT: What a guess I just made!:
> https://www.osronline.com/showthread.cfm?link=171655. Thanks Gavin,
> you just solved the problem for AFIO at least.

Yep, it appears so.  That makes life easier.

You should probably make it generic via IsReparseTagNameSurrogate as I 
mentioned earlier rather than checking for the symlink/dedup tags 
specifically.  So:

1. entries with FILE_ATTRIBUTE_DIRECTORY are directories.
2. entries with FILE_ATTRIBUTE_REPARSE_POINT *and* a tag with 
IsReparseTagNameSurrogate == true are symlinks.  (And possibly also 
directories, via #1.)
3. entries with FILE_ATTRIBUTE_REPARSE_POINT *and* a tag with 
IsReparseTagNameSurrogate == false are regular files that are possibly 
slow to open.
4. entries with FILE_ATTRIBUTE_COMPRESSED are regular files that are 
possibly slow to open.
5. entries with FILE_ATTRIBUTE_OFFLINE are regular files that are 
probably not openable (or *very* slow to open).
6. entries lacking those attributes are regular files.

Sound about right?

> The reason, I suspect, that CIFS is being so braindead here is that
> opening a deduped file is more expensive than usual and clients ought
> to know. Which is exactly why I am opposed to treating these things
> as a regular file.

I think they probably should be treated the same as files with 
FILE_ATTRIBUTE_COMPRESSED, since essentially it's just a different 
compression scheme.  I don't know whether you currently distinguish 
these from regular files or not.