Re: Invalid ACLS on windows file
> 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 ?
No, I don't think I do. For the use I need this for I think that hardlinks are provided another way.
> 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.
Hmmm... so, more complicated than I thought.
> 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).
OK. I haven't seen one of these yet either.
> I do not know what PROPERTY_DATA is. It must be
> the "$PROPERTY_SET" mentioned in
> with the (user) comment "The associated data stream
> is undocumented. Its usage is not clear."
> Do you have an example ?
I might have seen one go flying by the restore logs. I'll know more once I get OBJECT_ID's working and the logs
are reduced to a more sensible size :)
> 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.
I haven't yet looked into how BackupRead deals with encrypted streams.
> Finally, unless I get more information, only OBJECT_ID
> appears as eligible for extra support, with a specific
> > 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
> 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 !
I haven't written any code yet, but in looking through your code I think I mostly just need to replicate a
similar code path as for existing attributes, eg:
. Create a ntfs_object_id entry
. Create a routine to read/write - call ntfs_attr_readall etc with AT_OBJECT_ID
. Create some validation for write's - your assistance is probably required here, although if I can find
some documentation on the structure I can probably put something together myself
Thanks for considering this.
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!