Re: [PATCH] hfsplus: Remove hfsplus_file_lookup

[Vyacheslav Dubeyko]

On Dec 11, 2013, at 7:56 PM, Sougata Santra wrote:

[snip]
> In OSX, we can open "file/rsrc" to get the resource fork of "file".
> This behavior is emulated inside hfsplus on Linux, which means that
> to some degree every file acts like a directory. That is the reason
> lookup() inode operations is supported for files, and it is possible
> to do a lookup on this specific name. As a result of this open succeeds
> without returning  ENOTDIR for HFS+
> "
> Please see the LKML discussion thread on this issue:
> http://marc.info/?l=linux-fsdevel&m=122823343730412&w=2 
> 
> I tried to test file/rsrc lookup in HFS+ driver and the feature does not work.
> From OSX:
> $ touch test
> $ echo "1234" > test/..namedfork/rsrc
> $ ls -l test..namedfork/rsrc
> --rw-r--r-- 1 tuxera staff 5 10 dec 12:59 test/..namedfork/rsrc
> 
> [sougata@ultrabook tmp]$ id
> uid=1000(sougata) gid=1000(sougata) groups=1000(sougata),5(tty),18(dialout),1001(vboxusers)
> 
> [sougata@ultrabook tmp]$ mount
> /dev/sdb1 on /mnt/tmp type hfsplus (rw,relatime,umask=0,uid=1000,gid=1000,nls=utf8)
> 
> [sougata@ultrabook tmp]$ ls -l test/rsrc
> ls: cannot access test/rsrc: Permission denied
> 
> According to this LKML thread it is expected behavior.
> http://marc.info/?t=121139033800008&r=1&w=4
> I guess now that permission checking happens in vfs generic_permission() ?
> So it turns out that even though the lookup() inode_operation exists for HFS+ files.
> It cannot really get invoked ?. So if we can disable this feature to make opendir()
> work for HFS+.
> 

This feature worked earlier under Linux. So, I suppose that some changes in HFS+ driver
or in VFS broke it. And it needs to investigate and fix the reported issue. Thank you for the
report.

But I think that this patch can't be the solution of the issue. So, if you want then
you can investigate and fix the issue. Could you do it?

Thanks,
Vyacheslav Dubeyko.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/