--one-file-system complains about "supermount" file systems

[Eric Siegerman]

This is in reference to GNU Tar 1.13.25.

Command and results:
    # cd /mnt
    # tar --one-file-system -cf - . >/dev/null
    tar: ./cdrom: Cannot savedir: Input/output error
    tar: ./floppy: Cannot savedir: Input/output error
    tar: Error exit delayed from previous errors
    # echo $?
    2
    #

What should happen:
    No error messages, and a 0 exit status.

How to reproduce:
    On a system with "supermount" capability:
      - mount a removable drive using supermount
      - make sure the drive is empty
      - "tar --one-file-system -cf - <dir>", where <dir> is the
        parent (or higher) of the drive's mount point

Background:
    This is a Mandrake Linux 7.2 system (kernel version
    2.2.17-21mdk), on which /mnt is *not* itself a mount point;
    rather, it contains a number of subdirectories that are so
    used (/mnt/win_c for my Windows partition, various NFS and
    Samba mounts, etc).  Tar correctly ignores most of these.
    
    The two that it complains about, /mnt/cdrom and /mnt/floppy,
    are the only two removable-media devices on the box.  They're
    both mounted as "supermount" file systems -- that's a
    mechanism for automatically handling insertion/removal of
    removable media.

Details:
    This problem occurs when the drive(s) are empty, such that
    attempts to read from them result in EIO errors:
        # dd bs=1k count=1 </mnt/floppy >/dev/null
        bash: /mnt/floppy: Input/output error
    but still "mounted" as far as the kernel is concerned, so
    that descending into the mount-point directory also tries to
    access the device:
        # ls /mnt/floppy
        ls: /mnt/floppy: Input/output error
    (If I were to insert a (formatted) floppy and try the "ls"
    again, the command would succeed, courtesy of the supermount
    machinery.)

Possible fix:
    The bug seems to be that dumpfile() calls savedir() *before*
    it tests whether it has crossed a mount point.  My first
    guess at a fix would be to move this block of code:
      if (one_file_system_option && !top_level
                && parent_device != current_stat.st_dev)
        {
            ....
        }

    up so that it comes between these two lines:
        errno = 0;
        directory = savedir (p);

    But there's enough happening between those two locations that
    I don't know what my naive approach might break.  That's why
    I'm just describing it, rather than providing it as a patch :-)

Notes:
    - If I *don't* specify --one-file-system, I believe that
      the error messages I've described *are* acceptable

    - The tests were done as root to eliminate any suspicion of
      permissions problems, but I believe that to be immaterial


ISSUES (possible related bugs?):
    - Even with --one-file-system (and in the absence of the
      above situation, of course), the file system's mount point
      *is* included in the archive.  Is that intended?

    - The test is:
          if (one_file_system_option && !top_level
                    && parent_device != current_stat.st_dev)
      But the comments at the top of dump_file() say:
          [top_level being] negative means an incremental dump

      Those two together suggest that --one-file-system is
      ignored for incremental dumps.  Is this correct?  If so, is
      it intended?

Thanks much.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
My Wine works.  However it crashes about half the time on startup.
Apparently their simulation of windoze API is getting too accurate.  :)
        - Kyle Sallee