In my setup I have custom directories specified for portage: DISTDIR="/usr/portage/_distfiles" PKGDIR="/usr/portage/_packages" During `emerge --sync` or `emerge-webrsync` emerge removes both of those directories including all files within. This is easiest to notice with `emerge --sync`: <snip...> receiving incremental file list deleting _packages/ deleting _distfiles/.locks/ deleting _distfiles/gnuconfig-20080928.tar.bz2 deleting _distfiles/ deleting .ebuild.x ./ app-accessibility/ app-accessibility/dasher/ app-accessibility/emacspeak/ <snip...> The only difference is that in case of using `emerge-webrsync` those are removed at the end of sync process. It seems that by default portage removes all directories from dir. I have created one named foo (not referenced by any portage vars) and it was also removed, what might indicate that this problem might be sorted by changing some rsync options used, etc. I have never noticed similar issues while using default "/usr/portage/distfiles" and "/usr/portage/packages". If it will be decided to leave it as it is (reject this bug), then it would be wise to make explicit comment in man page of make.conf, as current "Note that locations under /usr/portage are not necessarily safe for data storage" is not very explicit (maybe make reference to description of PORTDIR, where it is explained better). Or maybe there might be warning added at the beginning of emerge process informing that everything added to portage directory will be removed? Tested on x86 with portage-2.2_rc38 (~x86 system) and amd64 with portage-2.1.6.13. Both are machines with two cores, but I don't think it is irrelevant. Reproducible: Always
The subdirectories 'local', 'packages' and 'distfiles' are explicitly excluded by the "emerge --sync" operation. You should either store your "custom directories" under $PORTDIR/local, or outside of $PORTDIR entirely.
It's also possible to use PORTAGE_RSYNC_EXTRA_OPTS in make.conf to exclude custom directories. Personally I'd recommend using the local subdir or another location entire as these are guaranteed to never conflict.
*** Bug 281469 has been marked as a duplicate of this bug. ***
