pdumpfs omits extra files when --exclude is used on certian large directory trees

Bug #516946 reported by Pallinger Péter on 2010-02-04
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pdumpfs (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: pdumpfs

I hit together a small "script" to test this behaviour:

SRC=/home; mkdir -p /tmp/dump/; pdumpfs -n --exclude 'fjhrqwphfeuiqwph' $SRC /tmp/dump/ |cut -c14- | sort > /tmp/1 ; find $SRC | sort | diff - /tmp/1|less

The output should be empty, except if you do have a file called 'fjhrqwphfeuiqwph'. :)
You can test that by removing the --exclude option, the difference disappears.
Interestingly, the error is produced for /home and /proc (for proc, not only the since ended and started processes account for the difference), but it is not produced for /usr, /lib, /var, /dev and /sys. I am yet to find a small directory tree that produces the error, it is maybe due to some special kinds of files, or some files changing during the pdumpfs process, etc.

Upon inserting some debug messages into the recursive_copy function (see below), it seems that the files are not excluded, but are not in the internal list of files at all (there was no output beginning with 'excluding:').
        if @matcher.exclude?(s)
          wprintf("excluding?: %s", s)

I got somewhat stuck, as I am not familiar with ruby. I may investigate further if I will have the time, but any help would be welcome (e.g. results of running the above script at your machines, etc.).

--------------------
system info:

Description: Ubuntu 9.10
Release: 9.10

pdumpfs:
  Telepítve: 1.3-3
  Jelölt: 1.3-3
  Verziótáblázat:
 *** 1.3-3 0
        500 http://hu.archive.ubuntu.com karmic/universe Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
Date: Thu Feb 4 08:44:09 2010
DistroRelease: Ubuntu 9.10
Package: pdumpfs 1.3-3
PackageArchitecture: all
ProcEnviron:
 LANG=hu_HU.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: pdumpfs
Uname: Linux 2.6.31-17-generic i686
XsessionErrors:
 (gnome-settings-daemon:4027): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:4027): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:4131): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:4156): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-panel:4130): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 24

Pallinger Péter (pp-publikus) wrote :
Pallinger Péter (pp-publikus) wrote :

Upon investigating further, it seems that the problem is caused by unreadable files. I think this because after copying a sub-directory tree in /home (which induced the error) except for one unreadable file (.gvfs), the copy didn't produce the error any more.
It would be good to catch the point when the program encounters the unreadable file, and what it does. It is quite interesting that the error is produced only if --exclude is specified.

Pallinger Péter (pp-publikus) wrote :

I found the error: the exclude code tries to lstat the file, which throws an exception that is not caught.
I modified the source to catch that exception, and now it seems to work well.

I included a full patch for the 1.3 upstream source, with changelog entry and a sub-minor version change.

Pallinger Péter (pp-publikus) wrote :

I have also sent an email to the upstream author, so maybe there will be a new upstream release soon.

Pallinger Péter (pp-publikus) wrote :

Does anyone know a contact to the upstream author? He does not seem to read his mail address...
Does the one responsible for this package read this bug report at all?

Daniel T Chen (crimsun) wrote :

This source package no longer ships in Oneiric, marking as closed

Changed in pdumpfs (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers