On Mon, Nov 02, 2015 at 12:53:18PM +0100, Jean-Pierre André wrote:
> This is simply because it is felt dangerous to
> meddle with objets whose purpose and structure
> are not known.
At the NTFS level, the high-level structure of a reparse point file is known:
it's a file with a reparse point attribute and FILE_ATTRIBUTE_REPARSE_POINT set.
libntfs-3g should make it possible for backup applications to correctly backup
and restore reparse points, even if their reparse tags are not recognized by
libntfs-3g. In the scenario being discussed, libntfs-3g enforces an unnecessary
restriction which makes this impossible in some cases.
Windows imposes no such restriction. On Windows, I can set a reparse point on a
nondirectory file using an arbitrary reparse tag, then set the short name of the
file and create an additional hard link (long name) to it, then delete all names
of the file. Of course, if you do something that actually requires
*dereferencing* the reparse point, you get an error saying that the system
cannot access the file; but there are no restrictions that I know of on
operations that do not dereference the reparse point.
> Actually I have had reports about problems with
> new compressed files. Better prevent users making
> bad decisions about them. Currently, if such a
> file is deleted, there is no way to recreate it.
I was actually concerned with reparse points more generally and did not have the
new compressed files in mind specifically, but they are certainly a case where
this limitation is likely to be encountered.
I don't agree that the inability to exactly replicate the original file should
prevent applications from deleting it or creating a link to it. A user might be
doing backup and restore, as has been my primary concern. A user also might be
doing something as simple as replacing one file with another.
> The usage of reparse points for compressed files was not anticipated, and
> adjustments have to be made. I have already pointed out these files can have
> both EA and REPARSE_DATA, which Microsoft still advertise as forbidden.
Making EA and REPARSE_DATA mutually exclusive will probably be an appropriate
restriction if Microsoft's implementation enforces the same restriction. That
is, however, a separate issue.
It is indeed somewhat strange that Microsoft implemented their new compression
feature using reparse points rather than adding a new compression method to
NTFS; there is space reserved in the ATTR_FLAGS specifically for future
compression methods, after all. I do not know the reasoning behind it. I
suppose they based the feature on "WIMBoot" which was already implemented using
reparse points, but they may find this was a mistake.
> I have also discovered that the presence of reparse tag in the name attribute
> is only done by windows for names created after the reparse tag is set
> (currently ntfs-3g never inserts the reparse tag in the name attribute). So
> you should not delay inserting the reparse point after all the names (again :
> no effect by ntfs-3g currently).
Each FILE_NAME is actually stored in two places, correct?
1. a FILE_NAME attribute of the file itself
2. an index entry in the parent directory
If Windows doesn't keep them up to date, it perhaps is acceptable if libntfs-3g
doesn't either. But it would be nice if it kept them up to date, I suppose.
> Also I am wondering whether some generic feature could be added to ntfs-3g to
> delegate the processing of reparse points to an external library.
This is, again, a separate issue. It may be a good idea from an architectural
point of view since it would make NTFS-3g more similar to the Windows
implementation and make it easier to support new reparse points. Are you
thinking that reparse point handlers would be written by third parties? I am
not sure how many third parties would be interested in that. To me it seems the
handlers should be supplied by NTFS-3g, although perhaps they could be made
modular and toggleable on/off.
I also have realized that in the case of wimlib specifically, the WIM file
format does not actually permit multiple long names per reparse point, so wimlib
isn't going to be handling reparse points with multiple (long name) hard links
correctly anyway. But the short name, if present and not collapsible, will
still result in the problem I have been describing --- indeed, I ran into it
during my testing.
Eric
------------------------------------------------------------------------------
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
