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! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/