pdumpfs omits extra files when --exclude is used on certian large directory trees
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pdumpfs (Ubuntu) |
Won't Fix
|
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.
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://
100 /var/lib/
ProblemType: Bug
Architecture: i386
Date: Thu Feb 4 08:44:09 2010
DistroRelease: Ubuntu 9.10
Package: pdumpfs 1.3-3
PackageArchitec
ProcEnviron:
LANG=hu_HU.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: pdumpfs
Uname: Linux 2.6.31-17-generic i686
XsessionErrors:
(gnome-
(gnome-
(nautilus:4131): Eel-CRITICAL **: eel_preferences
(polkit-
(gnome-
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.