Subject: Re: [boost] [filesystem] proposal: treat reparse files as regular files
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-29 07:12:07
On 29 Jul 2015 at 12:27, Paul Harris wrote:
> > I appreciate the problem with saying something is a symlink, but
> > trying to retrieve the target of that symlink has to error out
> > because it's meaningless in the case of a dedup symlink.
> Please stop calling it "dedup symlink". It is _not_ any kind of symlink.
> That is the point of misunderstanding, we are not on the same page.
It *is* a kind of symlink.
Deduped files on NTFS are kept as a chain of compressed fragments.
When you open the file handle, all that has to be decompressed and
rechained back together into a temporary inode.
This is why deduped files are so publicly marked because they are
much more expensive to open than regular files. I suspect that's why
CIFS exports the flag instead of actually treating the file as a
proper regular file because you want client programs to know this
isn't a regular file.
Anyway, thanks to Gavin I have a solution for AFIO which is optimal,
so I'll commit that shortly - these deduped files are going to get a
special flag, not least because handle::path() is going to return
something weird for the open file handle.
Beman has a trickier problem on his hands - he can either add a
special type of flag for these files and then the OP's code falls
through to is_regular_file and he's happy. Or he can filter out the
symlink flag when the reparse tag is a dedup, and always return a
regular file instead. I don't know which is better for Filesystem.
Thanks to Gavin for spotting that the reserved field in
WIN32_FIND_DATA is officially the reparse tag type!
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk