Oh, yes, there was a small conflict at the end of super.c when I applied to 3.5.3: --------------- @@ -641,6 +672,7 @@ static void __exit exit_hfsplus_fs(void) * destroy cache. */ rcu_barrier(); + hfsplus_destroy_attr_tree_cache(); kmem_cache_destroy(hfsplus_inode_cachep); } ---------------- 3.5.3 does not have the "rcu_barrier();" line for whatever reason - since the chunk seem to mean 'put "hfsplus_destroy_attr_tree_cache();" towards the end of __exit exit_hfsplus_fs() just before the last line', that's what I did. But as far as I remember that was the only conflict - that does not sound like what you describe though... Hin-Tak --- On Mon, 17/9/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> wrote: > Hi Hin-Tak, > > Now I understand clearly the reason of your issue. This is a > side effect of not clean patching of your kernel (3.5.3). I > worked with 3.4.6 kernel during implementation and I didn't > take into account some changing of hfsplus fs driver in next > kernel versions during patch set preparation. The 3.5.3 > kernel has changing in super.c file that can't be merged > automatically with my patch set. So, if you applied patch > set by means of git then super.c file was left unchanged. > But patch for super.c contains very important changing which > to build attributes tree during file system mount and to > destroy ones during umount. Thereby, you have warnings about > failed searching in system log because of absence > constructed attributes tree in memory. > > Currently, I am investigating issue with getting list of > attributes by means of getfattr. I am going to prepare new > patch set based under last actual kernel version after issue > resolving. > > With the best regards, > Vyacheslav Dubeyko. > > On Sep 15, 2012, at 8:49 PM, Hin-Tak Leung wrote: > > > --- On Sat, 15/9/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > wrote: > > > >> Hi Hin-Tak, > >> > >> On Sep 15, 2012, at 4:11 AM, Hin-Tak Leung wrote: > >> > >>> Vyacheslav Dubeyko wrote: > >>>> Hi, > >>>> > >>>> This patch adds support of manipulation by > >> attributes file. > >>>> > >>>> With the best regards, > >>>> Vyacheslav Dubeyko. > >>>> -- > >>>> From: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > >>>> Subject: [PATCH 4/4] hfsplus: add support > of > >> manipulation by attributes file > >>>> > >>>> This patch adds support of manipulation by > >> attributes file. > >>>> > >>>> Reported-by: Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> > >>>> Signed-off-by: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > >>> > >>> NACK. It does not work (i.e. cannot read > attributes of > >> files which have them), and also generates a lot > of > >> warnings, "hfs: xattr searching failed". > >>> > >>> The files I looked at are the font suitecase > files in > >> the /System/Library/Fonts directory. > >>> > >> > >> By the way, do you really confident that any file > in your > >> /System/Library/Fonts folder have any extended > attribute? > >> > >> On my Mac none file in /System/Library/Fonts folder > has any > >> extended attribute. Could you check presence on > extended > >> attributes under Mac OS X by means of `xattr -l` > command? > >> > >> With the best regards, > >> Vyacheslav Dubeyko. > > > > Sorry, that was a bit brief - I just have access to a > Mac OS X 10.7 box from time to time. > > > > - There are 4 font suitecase files, which shows up to > have file size zero under linux, but not on Mac OS X. I > formatted the thumb drive under Mac Os X and copied with > Finder, but of course it might be something I don't > understand in the process. > > > > - get a lot of "hfs: xattr searching failed" (about > 20-ish per command) when I run getfattr on linux. > > > > - It is a bit confusing apple talking about resource > forks and extended attributes as if they are they same > thing. > > > > As an aside, one of the older experients, shows it to a > few files with extended attributes > "com.apple.decmpfs". I looked it up, apple use this > atttribute to implement per-file compression - hiding the > file content compressed in the attribute while having the > data fork zero. (different and unrelated to the font issue). > This happens on mac os X 10.6 onwards. > > > > --- On Sat, 15/9/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > wrote: > > > >> Hi, > >> > >> On Sep 15, 2012, at 4:11 AM, Hin-Tak Leung wrote: > >> > >>> Vyacheslav Dubeyko wrote: > >>>> Hi, > >>>> > >>>> This patch adds support of manipulation by > >> attributes file. > >>>> > >>>> With the best regards, > >>>> Vyacheslav Dubeyko. > >>>> -- > >>>> From: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > >>>> Subject: [PATCH 4/4] hfsplus: add support > of > >> manipulation by attributes file > >>>> > >>>> This patch adds support of manipulation by > >> attributes file. > >>>> > >>>> Reported-by: Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> > >>>> Signed-off-by: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > >>> > >>> NACK. It does not work (i.e. cannot read > attributes of > >> files which have them), and also generates a lot > of > >> warnings, "hfs: xattr searching failed". > >>> > >>> The files I looked at are the font suitecase > files in > >> the /System/Library/Fonts directory. > >> > >> > >> Could you share kernel version that you are using? > >> > >> What utility do you use for getting of extended > attributes > >> list? I need more details for issue reproduction. > >> > >> Could you share some more detailed output of system > log > >> related to the issue? > > > > I patched over 3.5.3 with just the 4 patches. > > > > I also have some messy scripts based on work from the > iphone hackery people to look at details at the low-level. > > -- > > To unsubscribe from this list: send the line > "unsubscribe linux-fsdevel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html