Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 201459 - emerge removed all empty mountpoints in /mnt
Summary: emerge removed all empty mountpoints in /mnt
Status: RESOLVED OBSOLETE
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Python Gentoo Team
URL: http://forums.gentoo.org/viewtopic-p-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-06 05:54 UTC by Daniel
Modified: 2012-05-09 04:44 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2007-12-06 05:54:31 UTC
I emerged sci-visualization/qtiplot-0.9.2 yesterday at work, just before leaving. It took ages to finish 'cleaning old python code'. When I arrived home and brought the system back from suspend, most mountpoints -- all empty mountpoints I created in /mnt/ -- were gone, and I've noticed other empty directories in /home/myuser missing too. /mnt/floppy remained there, probably because it has a .keep file, while the mountpoints created by me would not have that file. So everything points to the emerge process cleaning up stuff in /mnt and maybe elsewhere (/home/), which is something it shouldn't be doing.
Comment 1 Zac Medico gentoo-dev 2007-12-06 06:05:39 UTC
It looks like this part of python_mod_cleanup() from python.eclass could have done it:

	# attempt to remove directories that maybe empty
	for dir in $(find ${path} -type d | sort -r); do
		rmdir ${dir} 2>/dev/null
	done

The above code isn't safe for spaces in paths, so that could trigger behavior like you've described.
Comment 2 Daniel 2007-12-06 06:24:41 UTC
That could have been true for the directories in /home, yes. But my mountpoints were named /mnt/andrew, /mnt/homebackup, /mnt/labbackup, /mnt/samba... No spaces in the path.
Comment 3 Steve L 2007-12-06 07:02:24 UTC
(In reply to comment #1)
>         # attempt to remove directories that maybe empty
>         for dir in $(find ${path} -type d | sort -r); do
>                 rmdir ${dir} 2>/dev/null
>         done
> 
> The above code isn't safe for spaces in paths, so that could trigger behavior
> like you've described.
> 
I am not sure if this is the source of the bug or not, but it's how to handle this kinda stuff in bash.

Expansion of path should be quoted, so find "$path" unless it's a list. rmdir "$dir" as well.
To get the filenames correctly from find, the robust method (which will deal with any possible path) is:
while read -rd ''; do
  file=$REPLY
  cmd -on "$file"
done < <(find dir .. -print0)

Using REPLY is safer since it won't have spaces chomped from beginning or end. -r means no backslash interpretation. We want to get the filenames exactly as find sends them. -print0 means NULL delimited ofc.

In this case there's an implicit newline separator since the data is piped through sort, so just using read without a delimiter will do it:
while read -r; do
  dir=$REPLY
  rmdir "$dir" 2>/dev/null
done < <(find "$path" -type d | sort -r)

If path is a list of directories, it really does make sense to use an array, eg if the list comes from a glob:
path=(*/)
find "${path[@]%/}" -name '*~' -exec rm {} +

In general it's better to write robust scripts that deal with all possible filenames without exception. Quotes, globs and arrays are the way to do that ime, as well as the wiki/#bash: http://wooledge.org/mywiki/UsingFind

HTH.
Comment 4 Mike Gilbert gentoo-dev 2012-05-09 04:44:26 UTC
AFAIK python.eclass no longer uses the for loop cited in comment 1.