Hi James, James Harper wrote: > Would you accept a patch which allowed the setting of raw data without any > validation? The data stream generated by the BackupRead API under Windows > contains DATA, ALTERNATE_DATA, EA_DATA, LINK, OBJECT_ID, PROPERTY_DATA, > REPARSE_DATA, SECURITY_DATA, and SPARSE_BLOCK streams. You handle most of > them already, but not OBJECT_ID which is one that I need. I can't see that it > would add much value to ntfs-3g for anything other than backup and restore. >
Doing that blindly is calling for problems. Examples : I guess "LINK" is defining alternate names for the file. Assuming the name space information is provided, setting a name is not just setting an attribute, the main purpose is to create an entry in the index of some directory. At least the information about the directory is needed. You must have solved that one, where did you get the directory from ? Do you have an example of backup data associated to a LINK attribute ? The same problem goes with "OBJECT_ID". Its purpose is to define a unique id is some domain, so that the file can be located in the domain. For the OBJECT_ID to be meaningful, it has to be indexed in a special file, which means special processing for this attribute. Also with "SECURITY_DATA", as each ACL is indexed twice in a special file. This situation a currently dealt with, which gives indications to what has to be done for OBJECT_ID. As far as I understand, "SPARSE_BLOCK" is not an attribute of the file, but rather an information needed to decode DATA or ALTERNATE_DATA when the stream is sparse (to avoid backing up holes). I do not know what PROPERTY_DATA is. It must be the "$PROPERTY_SET" mentioned in http://msdn.microsoft.com/en-us/library/bb470038(VS.85).aspx with the (user) comment "The associated data stream is undocumented. Its usage is not clear." Do you have an example ? I would add that "EA_DATA" is considered obsolete, as the only known reference to it in Win32 are the backup and restore function. The EA_DATA were the extended attributes on OS2, and the ADS is now used for this purpose. And in your list there is nothing about encrypted files which use the attribute "$LOGGED_UTILITY_STREAM" and have significant data beyond the advertised stream size. Finally, unless I get more information, only OBJECT_ID appears as eligible for extra support, with a specific processing. > Do the xattr namespaces have to be pre-registered with Linux, or can I create > something like 'system.ntfs_raw_X' where X is the hex value that corresponds > to the data stream? > I do not know of any registration process for the extended attributes in system name space. I consider that prefixing by "ntfs_" is enough to avoid conflicts. The attributes in system name space are not returned by listxattr(), consequently they cannot be wrongly processed by applications which do not know about them. For the OBJECT_ID, I acknowledge they can be needed in a networked environment and may have to be backed up. I can add support for them if you provide me with examples... (should take a few weeks). I can also merge the patches you would send me ! Regards Jean-Pierre ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
