Re: 2.6.29 -mm merge plans

Roman Zippel
2009-01-12T04:22:17Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=UTF-8, Size: 1347 bytes --]

Hi,

On Wed, 7 Jan 2009, Diego E. 'Flameeyes' Pettenò wrote:

> Yes that one wasn't good at all, and I feel sorry for not having noticed
> that before sending it in the first place.

In general you could also use the create_date field to initialize the
generation field (it's set in hfsplus_cat_build_record and should be read
in hfsplus_cat_read_inode). (BTW OS X doesn't use create_date because it
can be changed by the user, which isn't an issue for Linux).
I have some doubts about the hfsplus_get_parent() function. One has to
know about HFS+ that every hard link has it's own link id (which is
usually not visible) and the common inode id. If you lookup the parent
like this you expose the usually hidden and private directory.
The link id is stored in d_fsdata under Linux, which seems not to be
restored by hfsplus_fh_to_dentry(), so any catalog manipulations are
likely to hit the wrong catalog entry. Any catalog change requires the
correct link id, but with just the common id you currently can't find back
the link entry.
Newer HFS+ OS X driver support a link chain, which would make it possible
to find back the link entry using the common id and create_date in case
the normal file became a hard link, but this isn't implemented under Linux
yet.
So it seems the hard link handling may need a bit more work...

bye, Roman