Skip to content

Conversation

@jsmeix
Copy link
Member

@jsmeix jsmeix commented Oct 26, 2016

re-numbered 00_ 01_ and 99_ scripts
to get 00_ 01_ and 99_ free and reserved
for user scripts see
#1022 (comment)

@jsmeix jsmeix added the cleanup label Oct 26, 2016
@jsmeix jsmeix added this to the Rear v1.20 milestone Oct 26, 2016
@jsmeix jsmeix self-assigned this Oct 26, 2016
@jsmeix
Copy link
Member Author

jsmeix commented Oct 26, 2016

Do not yet merge it.
I need to test it first...

@jsmeix jsmeix modified the milestones: Rear v1.20, Rear future Oct 26, 2016
@jsmeix
Copy link
Member Author

jsmeix commented Oct 26, 2016

I cannot do a re-numbering with reasonable effort
because currently ReaR works too fragile because
it runs the various backup-method specific scripts
somehow intermixed with the generic scripts.

Therefore re-numbering of generic scripts results
a different sequence how the generic scripts are run
intermixed with the backup-method specific scripts.

For example when I use "BACKUP=NETFS"
a "rear -s mkbackup" before and after my current
re-numbering results (diff output):

-Source prep/default/00_remove_workflow_conf.sh
-Source prep/default/02_translate_url.sh
-Source prep/default/03_translate_tape.sh
-Source prep/default/04_check_output_scheme.sh
+Source prep/default/02_remove_workflow_conf.sh
+Source prep/default/03_translate_url.sh
+Source prep/default/04_translate_tape.sh
 Source prep/NETFS/default/05_check_NETFS_requirements.sh
-Source prep/default/05_check_keep_old_output_copy_var.sh
+Source prep/default/05_check_output_scheme.sh
+Source prep/default/06_check_keep_old_output_copy_var.sh
...
+Source backup/default/98_post_backup_script.sh
 Source backup/NETFS/default/98_umount_NETFS_dir.sh
-Source backup/default/99_post_backup_script.sh

I.e. before it was:

Source prep/default/03_translate_tape.sh
Source prep/default/04_check_output_scheme.sh
Source prep/NETFS/default/05_check_NETFS_requirements.sh
Source prep/default/05_check_keep_old_output_copy_var.sh
Source prep/NETFS/default/06_mount_NETFS_path.sh
...
Source backup/NETFS/default/97_remove_lock.sh
Source backup/NETFS/default/98_umount_NETFS_dir.sh
Source backup/default/99_post_backup_script.sh

and after re-numbering it gets:

Source prep/default/04_translate_tape.sh
Source prep/NETFS/default/05_check_NETFS_requirements.sh
Source prep/default/05_check_output_scheme.sh
Source prep/default/06_check_keep_old_output_copy_var.sh
Source prep/NETFS/default/06_mount_NETFS_path.sh
...
Source backup/NETFS/default/97_remove_lock.sh
Source backup/default/98_post_backup_script.sh
Source backup/NETFS/default/98_umount_NETFS_dir.sh

I would have to verify and adapt for each backup method
also the backup-method specific scripts to keep the same
sequence how the generic scripts are run intermixed
with the backup-method specific scripts.

Perhaps at a later time when the issue becomes more pressing
we should do a general re-numbering probably with 3-digit
numbers 010_ ... 990_ to clean it up completely.

But for now I keep it as is to avoid regressions.

@schlomo
Copy link
Member

schlomo commented Oct 26, 2016

Actually renumbering everything from 501 to 599 sounds like a nice idea. Should be possible to do without breaking anything and gives lots of space before and after. Or somehow map 01..99 to 100..900 evenly.

@jsmeix
Copy link
Member Author

jsmeix commented Oct 27, 2016

I am thinking about a dumb adding of a trailing '0'
to all current numbers, i.e. this mapping
00 -> 000
01 -> 010
02 -> 020
...
99 -> 990
which is mathematically a dilatation by the constant
factor 10 that preserves topology/neighbourhood.

With the first step the old numbers 01 and 99
become 010 and 990 and those are already
no longer at the edges of the range 000..999.

The only old number that is still at the edge
is 00 which becomes 000 and that one needs
an actual re-numbering (i.e. movement) a bit away
from the edge but not more than where the old 01
is now (i.e. 010) so that a second step the actual
re-numbering could be this mapping:
000 -> 005

At the end the topology/neighbourhood did not change.

I think even the symlinks can be easier adapted this way
because their target usually only canges from NM_* to NM0_*
and only if the target is 00_* it needs to be changed to 005_*
(i.e. I can adapt the symlinks in a dumb mechanical way)

This way it looks sufficiently easy and fail-safe.
I think I will do it right now, but via a new pull request.

@jsmeix
Copy link
Member Author

jsmeix commented Oct 27, 2016

Furthermore because in very most cases only a trailing '0'
is added it is easier to also adapt all texts where the old
script names are used in a dumb mechanical way:
"NM_foo_bar.sh" -> "NM0_foo_bar.sh"
"00_blah.sh" -> "005_blah.sh"

@jsmeix
Copy link
Member Author

jsmeix commented Oct 27, 2016

See #1053
how it goes on...

jsmeix added a commit that referenced this pull request Oct 27, 2016
…rticular_for_user_scripts_see_comment_in_pull_request_1051

Renumbering all scripts (NM becomes NM0)
to get more free number space
 in particular for user scripts, cf.
#1051 (comment)

Renumbered by ading a trailing 0 so that 12 becomes 120
except 00 which becomes 005 and adapted symlinks
to point again to the right re-numbered scripts, cf
#1051

Adapted the SourceStage function in framework-functions.sh
for scripts with the new 3-number digits (instead of two before).

Adapted the texts (in particular the comments in the scripts)
to the new 3-number digits of the scripts where possible.

Nevertheless this renumbering may cause regressions
for special cases that I missed.

This renumbering will cause regressions for users who have
their own 2-digit scripts because now only 3-digit scripts will
work (see the SourceStage function in framework-functions.sh)
so that 2-digit user scripts must be renamed to 3-digit names.

Depending on how many users are hit by that regression we
could later think about an automated way how to support
also 2-digit scripts: My immediate idea is to handle a NM_name
script as if its name was NM0_name (or perhaps to simply
rename them automatically from NM_name to NM0_name?

think about
@jsmeix jsmeix deleted the re_number_scripts_to_get_01_and_99_reserved_for_user_scripts_see_comment_in_pull_request_1022 branch October 27, 2016 15:52
@jsmeix jsmeix removed this from the ReaR 999 (future) milestone Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants