On Thu, Dec 12, 2013 at 10:35:01AM +0400, Vyacheslav Dubeyko wrote:
> I think that I can implement support of resource forks by means of xattr
> way. Also, currently, I am implementing HFS+ compressed files support.
> So, I can clean up old-fashioned way of resource forks support in HFS+
> driver b
The opendir issue is something that came up before, both in the reiser4
context and with hfsplus. I think we'll need to put this patch in ASAP
to fix the semantic breakage caused by it, as well as other implications
of having ->lookup on a hardlinkable object.
Acked-by: Christoph Hellwig
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 i
Hi,
On 11 Dec 2013, at 19:11, Al Viro wrote:
> On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
>> 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.
>> Than
On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
> 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.
This "feature" is severely
From: Sougata Santra
HFS+ resource fork lookup breaks opendir() library function. Since
opendir first calls open() with O_DIRECTORY flag set. O_DIRECTORY
means "refuse to open if not a directory". The open system call
in the kernel does a check for inode->i_op->lookup and returns
-ENOTDIR. So if
