rmlint by default names creates rmlint.sh which when run performs the actual deletions.
rmlint.sh leverages rmlint itself to compare directories using the same default parameters, including creating an rmlint.sh output file, overwriting the rmlint.sh that the user started to perform the rmlint generated deletions! The original instance of rmlint.sh almost immediately starts to mess up, and soon gets a syntax error and bombs out. I think (hope?) that this is very unlikely to cause a dry run to actually delete data, but there is risk if real data loss if the rmlint.sh is actually deleting files. Of course in the process this also destroys all of the output files from the original run.
I assume that most of the readers of this note recognize this an see this as a user error, which it is, however to me the user has been set up to encounter the problem by the examples that just use the defaults, and actually by the existence of defaults. Unique output filenames must be provided as it stands, the defaults can never be used if a directory compare will be triggered. (Clearly there is something I don't understand here, because I did not specify -D (--merge-directories) yet the directory compare was triggered!)
If I understand what is happening correctly, possible solutions are:
[1] Update the documentation to state that the default cannot be used for the user output file because the same name will be used for directory compares. This however is not sufficient in the event that concurrent rmlints running in the same directory because rmlints forked by check_for_equality in the two instances would collide.
[2] Generate a guaranteed unique filename for check_for_equality's use of rmlint. This is the best answer. It leaves the user to his own decisions and hides rmlint's internal use.
I have attached the tail end of a typescript when running rmlint.sh as a dry run.
typescript.shrun.tail.log
cebtenzzre
commented
1 year ago
rmlint by default names creates rmlint.sh which when run performs the actual deletions.
rmlint.sh leverages rmlint itself to compare directories using the same default parameters, including creating an rmlint.sh output file, overwriting the rmlint.sh that the user started to perform the rmlint generated deletions! The original instance of rmlint.sh almost immediately starts to mess up, and soon gets a syntax error and bombs out. I think (hope?) that this is very unlikely to cause a dry run to actually delete data, but there is risk if real data loss if the rmlint.sh is actually deleting files. Of course in the process this also destroys all of the output files from the original run.
I assume that most of the readers of this note recognize this an see this as a user error, which it is, however to me the user has been set up to encounter the problem by the examples that just use the defaults, and actually by the existence of defaults. Unique output filenames must be provided as it stands, the defaults can never be used if a directory compare will be triggered. (Clearly there is something I don't understand here, because I did not specify -D (--merge-directories) yet the directory compare was triggered!)
If I understand what is happening correctly, possible solutions are:
[1] Update the documentation to state that the default cannot be used for the user output file because the same name will be used for directory compares. This however is not sufficient in the event that concurrent rmlints running in the same directory because rmlints forked by check_for_equality in the two instances would collide.
[2] Generate a guaranteed unique filename for check_for_equality's use of rmlint. This is the best answer. It leaves the user to his own decisions and hides rmlint's internal use.
I have attached the tail end of a typescript when running rmlint.sh as a dry run. typescript.shrun.tail.log