On Tue, Feb 25, 2014 at 08:01:16PM +0200, sougata wrote:
> > snip <=
> #define hfs_btree_open hfsplus_btree_open
> #define hfs_btree_close hfsplus_btree_close
> #define hfs_btree_write hfsplus_btree_write
> #define hfs_bmap_alloc hfsplus_bmap_alloc
> #define hfs_bmap_free hfsplus_bmap_free
On 02/24/2014 11:48 PM, Andrew Morton wrote:
On Mon, 24 Feb 2014 21:28:27 +0200 Sougata Santra wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the FS in an
On Tue, 2014-02-25 at 12:05 +0200, sougata santra wrote:
> return err;
> >> +
> >> + len = be16_to_cpu(key->cat.name.length);
> >>key->key_len = cpu_to_be16(6 + 2 * len);
> >
> > I think that maybe it is time to change hardcoded 6 on sensible named
> > constant. What do you
On 02/25/2014 09:37 AM, Vyacheslav Dubeyko wrote:
Hi Sougata,
On Mon, 2014-02-24 at 21:28 +0200, Sougata Santra wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the
On 02/25/2014 09:37 AM, Vyacheslav Dubeyko wrote:
Hi Sougata,
On Mon, 2014-02-24 at 21:28 +0200, Sougata Santra wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the
On Tue, 2014-02-25 at 12:05 +0200, sougata santra wrote:
return err;
+
+ len = be16_to_cpu(key-cat.name.length);
key-key_len = cpu_to_be16(6 + 2 * len);
I think that maybe it is time to change hardcoded 6 on sensible named
constant. What do you think?
I agree,
On 02/24/2014 11:48 PM, Andrew Morton wrote:
On Mon, 24 Feb 2014 21:28:27 +0200 Sougata Santrasoug...@tuxera.com wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving
On Tue, Feb 25, 2014 at 08:01:16PM +0200, sougata wrote:
snip =
#define hfs_btree_open hfsplus_btree_open
#define hfs_btree_close hfsplus_btree_close
#define hfs_btree_write hfsplus_btree_write
#define hfs_bmap_alloc hfsplus_bmap_alloc
#define hfs_bmap_free hfsplus_bmap_free
Hi Sougata,
On Mon, 2014-02-24 at 21:28 +0200, Sougata Santra wrote:
> -ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
> allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
> incorrect keys, leaving the FS in an inconsistent state. This patch fixes
>
On Mon, 24 Feb 2014 21:28:27 +0200 Sougata Santra wrote:
>
> -ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
> allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
> incorrect keys, leaving the FS in an inconsistent state. This patch fixes
> this
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the FS in an inconsistent state. This patch fixes
this issue.
Signed-off-by: Sougata Santra
Reviewed-by: Christoph Hellwig
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the FS in an inconsistent state. This patch fixes
this issue.
Signed-off-by: Sougata Santra soug...@tuxera.com
Reviewed-by:
On Mon, 24 Feb 2014 21:28:27 +0200 Sougata Santra soug...@tuxera.com wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the FS in an inconsistent state. This patch
Hi Sougata,
On Mon, 2014-02-24 at 21:28 +0200, Sougata Santra wrote:
-ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
incorrect keys, leaving the FS in an inconsistent state. This patch fixes
14 matches
Mail list logo
