1. 30 Jul, 2009 4 commits
  2. 24 Jul, 2009 1 commit
  3. 18 Aug, 2009 1 commit
  4. 14 Aug, 2009 1 commit
  5. 04 Aug, 2009 1 commit
  6. 31 Jul, 2009 4 commits
  7. 13 Jul, 2009 1 commit
  8. 21 Nov, 2008 1 commit
    • Warren Turkal's avatar
      This is a patchset to change the way that the HFS+ filesystem detects · 0ba79e5d
      Warren Turkal authored
      whether a volume has a journal or not.
      
      The code currently mounts an HFS+ volume read-only by default when a
      journal is detected.  One can force a read/write mount by giving the
      "force" mount option.  The current code has this behavior since there is
      no support for the HFS+ journal.
      
      My problem is that the detection of the journal could be better.  The
      current code tests the attribute bit in the volume header that indicates
      there is a journal.  If that bit is set, the code assumes that there is a
      journal.
      
      Unfortunately, this is not enough to really determine if there is a
      journal or not.  When that bit is set, one must also examine the journal
      info block field of the volume header.  If this field is 0, there is no
      journal, and the volume can be mounted read/write.
      
      
      This patch:
      
      The HFS+ support in the kernel currently will mount an HFS+ volume
      read-only if the volume header has the attribute bit set that indicates
      there is a journal.  The kernel does this because there is no support for
      a journalled HFS+ volume.
      
      The problem is that this is only half of what needs to be checked to see
      if there really is a journal.  There is also an entry in the volume header
      that tells you where to find the journal info block.  In the kernel
      version of the kernel, this 4 byte block is labeled reserved.  This patch
      identifies the journal info block in the header.
      Signed-off-by: default avatarWarren Turkal <wt@penguintechs.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      0ba79e5d
  9. 17 Aug, 2009 1 commit
  10. 18 Jul, 2009 2 commits
    • Andrew Morton's avatar
      ERROR: "(foo*)" should be "(foo *)" · ce6d8bf8
      Andrew Morton authored
      #62: FILE: fs/minix/dir.c:481:
      +		struct inode *inode = (struct inode*)mapping->host;
      
      total: 1 errors, 0 warnings, 46 lines checked
      
      ./patches/v3-minixfs-add-missing-directory-type-checking.patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: "Doug Graham" <dgraham@nortel.com>
      Cc: Doug Graham <dgraham@nortel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      ce6d8bf8
    • Doug Graham's avatar
      There are a few places in the Minix FS code where the "inode" field of a · 38a369d4
      Doug Graham authored
      minix_dir_entry is used without checking first to see if the dirent is
      really a minix3_dir_entry.  The inode number in a V1/V2 dirent is 16 bits,
      whereas that in a V3 dirent is 32 bits.
      
      Accessing it as a 16 bit field when it really should be accessed as a 32
      bit field probably kinda sorta works on a little-endian machine, but leads
      to some rather odd behaviour on big-endian machines.
      Signed-off-by: default avatarDoug Graham <dgraham@nortel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      38a369d4
  11. 13 Jul, 2009 1 commit
  12. 20 Aug, 2009 2 commits
  13. 06 Aug, 2009 1 commit
  14. 03 Aug, 2009 2 commits
  15. 31 Jul, 2009 1 commit
  16. 20 Aug, 2009 4 commits
  17. 15 Aug, 2009 1 commit
  18. 06 Aug, 2009 2 commits
  19. 31 Jul, 2009 2 commits
  20. 25 Jul, 2009 2 commits
  21. 31 Jul, 2009 1 commit
  22. 25 Jul, 2009 1 commit
  23. 31 Jul, 2009 1 commit
  24. 24 Jul, 2009 2 commits