5 Replies Latest reply on Sep 5, 2014 2:45 AM by DoC_CSG

    Bug: Adobe Reader 64-bit inode problem

    DoC_CSG Level 1

      Adobe Reader version: 9.3.3 (same issue also arises in later versions).

      Operating System: 64-bit Ubuntu Linux 10.04

       

      Synopsis: Adobe Reader will is unable to properly 'stat' on XFS mounted with '-o inode64' option.

       

      How to reproduce the problem:

      ======================

      - make an XFS greater than one terabyte in capacity ('man mkfs.xfs' for details):

       

      mkfs.xfs /dev/sda

       

      - mount the XFS with the '-o inode64' option ('man mount' for a full explanation of

      the implications of this):

       

      mount -o inode64 /dev/sda /mnt/blah

       

      - fill the file-system to near capacity.

       

      - now launch Adobe reader, setting one's home to be somewhere on the XFS:

       

      [tcsh]

      (setenv HOME /mnt/blah; acroread)

       

      [bash]

      (HOME=/mnt/blah; acroread)

       

       

      Result:

      An 'Internal error' is reported in a dialog; Adobe Reader fails to start.

      ".xsession-errors' contains 'failed to create ~/.adobe' messages.

      ==================

       

      The man-page for 'mount' contains the following excerpt on the '-o inode64'

      mount-option for XFS:

       

      ===

      Indicates that XFS is allowed to create inodes at  any  location

      in  the  filesystem,  including those which will result in inode

      numbers occupying more than 32 bits of  significance.   This  is

      provided  for  backwards  compatibility, but causes problems for

      backup applications that cannot handle large inode numbers.

      ====

      Paradoxically, Adobe Reader can *open* PDFs that are located on an
      XFS file-system mounted with the '-o inode64' option.
      Is it possible that the code that attempts to stat the "~/.adobe" configuration
      directory is not using 64-bit stat operation?

        • 1. Re: Bug: Adobe Reader 64-bit inode problem
          DoC_CSG Level 1

          Has there been any update on this issue?  Given that a procedure for reproducing the issue has been provided, it would be very helpful if someone else - especially an Adobe representative - could report that the issue is indeed reproducible.

           

          Given that volume sizes are generally on the increase, it is important that this issue is resolved.  Please note that this is independent of Adobe Reader for Linux itself being a 32-bit application: it is possible for 32-bit applications to handle 64-bit inodes.

          • 2. Re: Bug: Adobe Reader 64-bit inode problem
            DoC_CSG Level 1

            Is there any chance of getting an answer to this question?

            Putting it plainly, does the latest version of Adobe Reader use 64-bit stat operations when trying to read a user's

            '~/.adobe' configuration folder?

             

            It would be very helpful if an Adobe Reader developer could comment on this issue.

            • 3. Re: Bug: Adobe Reader 64-bit inode problem
              GerbenR

              AdbeRdr9.5.1-1_i486linux_enu.tar.bz2 still has the same problem. I have a RHEL5 machine with a 61TB xfs filesystem, mounted with "inode64".

               

              I would like a resolution to this problem, too.

              • 4. Re: Bug: Adobe Reader 64-bit inode problem
                DoC_CSG Level 1

                There has been no reply from Adobe in this forums about this matter.  It has been over a year.

                We have implemented a crude work-around that sets one's home directory to be somewhere on a local file-system which does not have the 'inode64' mount option (/tmp):

                 

                [bash]

                HOME=`/bin/mktemp --directory` acroread

                 

                [(t)csh]

                (setenv HOME `/bin/mktemp --directory`; acroread)

                 

                This gets around the problem but since a new, random 'home' directory is created under /tmp,

                acroread will ask the end-user to agree to the terms & conditions each time it is launched. There is also no persistence of settings.

                 

                Our primary OS is Ubuntu Linux with users home directories on NFS home directory servers.

                If the local file-system on any of those servers is XFS with inode64 enabled, we encounter the problem.  Our intention is to use a dpkg-diversion of the acroread package to our script that launches with the alternate home directory where required:

                 

                ===

                #!/bin/sh -

                # Script to invoke Adobe Reader for Linux with a fake home directory

                # for users on a home directory server with 64-bit inodes.

                # Adobe Reader <= 9.5.X cannot handle 64-bit inode home dirs.

                 

                AUTOFSHOMES="/etc/auto.homes"

                # The real acroread is dpkg-diverted to /usr/bin/acroread-real.

                ACROREAD="/usr/bin/acroread-real"

                 

                # Make a note of user's actual home directory (/homes/xyz).

                ARHOME=$HOME

                 

                # SFBSERVERS = string list of known home directory servers

                # using 64-bit inodes.  Additions to this list should be

                # in the form of a grep pattern: (A|B|C|D).

                SFBSERVERS="(server1|server2|server3)"

                 

                # Check for matching autofs entry for user.

                  if grep --perl-regexp --ignore-case --silent

                "^${USER}\t${SFBSERVERS}\." ${AUTOFSHOMES} ; then

                     ARHOME=`/bin/mktemp --directory`

                     STATUS=$?

                     if [ ! $STATUS -eq 0 ]; then

                        /bin/echo -e "Your home directory is on a server where 64-bit

                inodes are enabled.\nacroread does not work correctly on such servers.

                We tried to launch\nacroread with a 'fake' home directory as a

                work-around but that too\nfailed as there is no space for such a

                directory under /tmp.\n"

                        exit 1

                     fi

                  fi

                HOME=$ARHOME exec $ACROREAD $@

                ===

                 

                It's a work-around of sorts but it would be very helpful if Adobe could at least comment on the issue and - better yet - address it.

                • 5. Re: Bug: Adobe Reader 64-bit inode problem
                  DoC_CSG Level 1

                  A bit of thread resurrection here but a comprehensive analysis and work-around (with caveats)

                  for this issue appear on the following web-page:

                   

                  http://www.tcm.phy.cam.ac.uk/sw/inodes64.html

                   

                  You can also check whether your might be affected by 64-bit inode issues by running 'stat':

                   

                  stat -c '%i' /home/yourhomedirectory

                   

                  stat -c '%i' /home/yourhomedirectory/.adobe

                   

                  If the result exceeds 4294967295 (i.e. 2^32-1), then you are affected.

                   

                  Thanks to the Theory of Condensed Matter research group at the Cavendish Laboratory, Cambridge

                  University, for the answer.