Re: 2.6.29 -mm merge plans

[Roman Zippel <zippel@linux-m68k.org>]

[-- 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