Gecko [ www.prositehelp.com ]

Name	Size	Permission	Date
AVA	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
BACULA	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
BAREOS	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
BLOCKCLONE	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
BORG	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
CDM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
DP	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
DUPLICITY	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
EXTERNAL	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
FDRUPSTREAM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
GALAXY	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
GALAXY10	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
GALAXY11	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
GALAXY7	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
GNU	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
ISO	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
Linux-arm	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
Linux-i386	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
Linux-ia64	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
Linux-s390	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
NBKDC	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
NBU	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
NETFS	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
NFS4SERVER	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
NSR	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
OBDR	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
OPALPBA	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
PPDM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
PXE	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
RAWDISK	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
RBME	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
RSYNC	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
SESAM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
TAPE	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
TSM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
USB	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
VEEAM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
YUM	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
ZYPPER	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
default	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
systemstate	[ DIR ]	drwxr-xr-x	2026-04-01 09:39
README	1.76 KB	-rw-r--r--	2026-04-01 09:39

Rename

This is the preparation part of ReaR (i.e. the 'prep' stage)
before starting the rescue/recovery system build phase.

You should not put scripts into this 'prep' stage that modify things
in ROOTFS_DIR or in VAR_DIR/recovery and VAR_DIR/layout because
scripts for ROOTFS_DIR belong to the 'rescue' stage and scripts
for VAR_DIR/recovery and VAR_DIR/layout belong to the 'layout' stages.

The 'prep' stage is used for preparing and configuring ReaR
for the later stages, e.g. auto-detect features or settings.

Therefore code in 'prep' should not modify ROOTFS_DIR (the rescue/recovery system)
but only manipulate ReaR variables or check and prepare requirements
so that the 'prep' stage can also be run by workflows which
do not make a rescue/recovery system.

Reasoning for ROOTFS_DIR:
Only those workflows that actually make a rescue/recovery system
by running the stages 'rescue', 'build', 'pack', and 'output'
(in particular the workflows mkrescue, mkbackup and mkopalpba)
should modify something in ROOTFS_DIR.
In contrast when other workflows that run the 'prep' stage (e.g. mkbackuponly)
modify something in ROOTFS_DIR then all those modifications will be lost
because no rescue/recovery system with those modifications is made.
So the problem is possible inconsistencies between what gets actually used
during "rear recover" (i.e. the last actually made rescue/recovery system)
versus what other workflows that run the 'prep' stage may need to have.
For example mkbackuponly may need a modified rescue/recovery system
when backup config variables need updated values in the recovery system
(e.g. an updated value for BACKUP_PROG_EXCLUDE or something similar).
The prep/default/990_verify_empty_rootfs.sh script checks at the end
of the 'prep' stage that ROOTFS_DIR is unmodified (i.e. still empty).