Renaming folder to deleted folder alters contents of text file?

[linux_reader]

My operating system:

#NAME="Linux Mint"
#VERSION="20.1 (Ulyssa)

Forward:
Let me start off by apologizing if I have made a foolish mistake. I'm honestly not sure if I should put this in the newbie section because I'm relatively new to shell scripting and I may well have overlooked something. However, I'm not sure if shell scripting is considered to be a newbie linux topic, and the script I wrote to illustrate what I think I found should not be run except by someone who knows exactly what it is doing, so I put this post here.

Honestly, I'm pretty much a newbie at this, and I don't normally post online, so I am really sorry if I made an error. However, if this is a genuine bug, I do want to try to help illustrate it so that it can get fixed.

Thank you in advance for your time, help, caution, patience, and understanding.

Problem:
I think I found a bug. If I run the script (enclosed below) from a file via terminal window (eg. bash script.sh), it outputs ~/results.txt saying "Second Folder"; but if I do so by copying and pasting the entire script into the command line of an open terminal window (after deleting the results of the first script, including the ~/Buggy folder), it outputs "First Folder". I don't know why this is.

To make matters worse, a similar script that I wrote does similar behavior on Raspbian, and I think I managed to observe this on Raspbian Buster via the GUI (that was what led to me writing this script in the first place, in order to reproduce what I'd found).

Lastly, while the script below reliably reproduces this for me, I haven't been able to reliably reproduce it when using just two files. I need to create the other files, nested folders, etc. Not sure why that is. Not sure if this is just a quirk of how I've set stuff up; that's why I am asking for help...


Questions:
Is this a bug? Or is this predefined behavior that is expected and I am somehow missing something? Any details/thoughts/etc. would be greatly appreciated.

Warning:
The Script below contains potentially dangerous commands such as "rm -R" and "mv". If you don't understand what it is doing, please don't run it. If you do understand what it is doing, please decide for yourself whether it is safe to run. I am new at scripting via bash (and shell scripting in general) and I can't guarantee that this won't break someone's computer or otherwise cause harm.


I am making the script below available under the MIT License (https://mit-license.org/); any use of the script requires first accepting said license. Please note in particular

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Thank you...

Script is here: (Note: I edited the script from its original version to replace ~ with "$HOME". I apologize for my error; I just realized later that if there was a space in the home directory, then the line "rm -IR ~/Buggy/fol2/f1" might (I am not sure) have had unintended side effects. Again, I am new to bash scripting and I may have made errors that could cause unintended side effects. Please do not run this script if you do not know exactly what it is doing.)

Script:

Code: Select all

# when run as a script, it produces "Second Folder" but when copied and pasted into the shell, it produces "First Folder" (remember to delete the "Buggy" folder between runs)
if [ -d "$HOME"/"Buggy" ]
then
echo "Not running test; please delete directory "$HOME"/Buggy; press any key to exit"
read
exit

else

cd "$HOME"
mkdir Buggy
cd Buggy
mkdir fol1
mkdir fol2
cd fol1
mkdir f1
mkdir f2
cd f1
mkdir f
cd f
echo "First_Folder" >> file.txt
cd ..
echo "1" > file.txt
fallocate -l 10MB file.txt
echo "2" > file.txt
fallocate -l 10MB file.txt
echo "3" > file.txt
fallocate -l 10MB file.txt
echo "4" > file.txt
fallocate -l 10MB file.txt
cd ..
cd f2
mkdir f
cd f
echo "Second_Folder" >> file.txt
cd ..
echo "11" > file.txt
fallocate -l 10MB file.txt
echo "22" > file.txt
fallocate -l 10MB file.txt
echo "33" > file.txt
fallocate -l 10MB file.txt
echo "44" > file.txt
fallocate -l 10MB file.txt
cp -r "$HOME"/Buggy/fol1/f1 "$HOME"/Buggy/fol2
cp -r "$HOME"/Buggy/fol1/f2 "$HOME"/Buggy/fol2
rm -IR "$HOME"/Buggy/fol2/f1
mv "$HOME"/Buggy/fol2/f2 "$HOME"/Buggy/fol2/f1
cd "$HOME"
cat "$HOME"/Buggy/fol2/f1/f/file.txt >> results.txt # If I am not making an error in my analysis then the output should be "Second_Folder", but it is "First_Folder" instead.

fi

# to reproduce, the contents of this file need to be copied/pasted into the terminal

# up-to-date as of Sat 04 Sep 2021

# present in
#PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
#NAME="Raspbian GNU/Linux"
#VERSION_ID="10"
#VERSION="10 (buster)"
#VERSION_CODENAME=buster
#ID=raspbian
#ID_LIKE=debian
#HOME_URL="http://www.raspbian.org/"
#SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
#BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

# also present in
#NAME="Linux Mint"
#VERSION="20.1 (Ulyssa)"
#ID=linuxmint
#ID_LIKE=ubuntu
#PRETTY_NAME="Linux Mint 20.1"
#VERSION_ID="20.1"
#HOME_URL="https://www.linuxmint.com/"
#SUPPORT_URL="https://forums.linuxmint.com/"
#BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
#PRIVACY_POLICY_URL="https://www.linuxmint.com/"
#VERSION_CODENAME=ulyssa
#UBUNTU_CODENAME=focal

[SimonPeter]

This script gives the result "Second_folder" in all these cases:
1) Copy-pasted into the Terminal (running bash)
2) Copy-pasted into the Terminal (running sh)
3) Run as a script with #!/bin/sh
4) Run as a script with #!/bin/bash

My system is Debian GNU/Linux 10 (Buster) .

[linux_reader]

Thank you very much for your time and help; it is a relief for me to learn that this is likely related to my local setup in some fashion.

I ran the tests mentioned above for both the bash shell and sh (my sh is set to dash for linux mint), and I got the same results that I did before. (Eg. "bash myscript.sh;" and "sh myscript.sh;" both write "Second_Folder" to "results.txt" and copy-pasting into the terminal to run (when said terminal is set to bash or sh) writes "First_Folder" to "results.txt". I used 'echo "$SHELL";' to check that I'd set the shell properly for Linux Mint.)

(To help clarify, since my environment is a bit weird, I ran the tests for bash and sh on my linux mint vm, and I just retested bash on my raspberry pi and bash on my linux mint (outside of vm). I got the same results for bash on the raspberry pi and linux mint outside of vm as I did for bash and sh in the linux mint vm. My linux mint vm runs on my laptop; it is not hosted in the cloud.)

If it is okay, I have a few more questions:

1. Is your computer using an hdd or an ssd?

Mine is an ssd for the laptop (with linux mint inside a vm, since I do all of my spare-time projects in various vms) and a micro-sd card for Raspbian Buster (as is the default for a Raspberry Pi).

The reason why I ask this question is that I suspect that this is an issue with something lower-level than the shell, although I would welcome your thoughts and suggestions. (Again, I am new to bash/shell scripting, so if you have any feedback or other tests that you think I should run, please let me know.)

2. Also, what version of bash and what version of sh are you using?

(I ask because, maybe I'm using an outdated version, or maybe the bug is specific to the GNU implementation?)

My versions of bash are:
Linux Mint (copied-and-pasted)
GNU bash, version 5.0.17(1)-release-(x86_64-pc-linux-gnu)

Raspbian Buster (typed from sight)
GNU bash, version 5.0.3(1)-release-(arm-unknown-linux-gnueabihf)

and my version of dash is:

dash:
Installed: 0.5.10.2-6
Candidate: 0.5.10.2-6
Version table:
*** 0.5.10.2-6 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status


In any case, thank you very, very much for your time and help; I was rather worried about this and, while I am still somewhat curious, this seems to be less of an issue than I thought.

[SimonPeter]

.....

This script gives the result "Second_folder" in all these cases:
1) Copy-pasted into the Terminal (running bash)
2) Copy-pasted into the Terminal (running sh)
3) Run as a script with #!/bin/sh
4) Run as a script with #!/bin/bash

My system is now running Debian GNU/Linux 11 (Bullseye) .

I have a HDD drive.

I have also run your script, replacing "$HOME" with /tmp
My /tmp is on tmpfs (ie. the /tmp folder is on RAM -- which is MUCH faster than almost all SSDs)

You can put /tmp on tmpfs by:

Code: Select all

sudo sed -i '/tmpfs.*\/tmp.*tmpfs/d' /etc/fstab
echo 'tmpfs  /tmp  tmpfs  defaults,rw,nosuid,nodev 0 0' | sudo tee --append /etc/fstab
sudo reboot

( can be undone with sudo sed -i '/tmpfs.*\/tmp.*tmpfs/d' /etc/fstab )

[SimonPeter]

....................

Eureka !

I could also reproduce it.

Original script:

Code: Select all

# when run as a script, it produces "Second Folder" but when copied and pasted into the shell, it produces "First Folder" (remember to delete the "Buggy" folder between runs)
if [ -d "$HOME"/"Buggy" ]
then
echo "Not running test; please delete directory "$HOME"/Buggy; press any key to exit"
read
exit

else

cd "$HOME"
mkdir Buggy
cd Buggy
mkdir fol1
mkdir fol2
cd fol1
mkdir f1
mkdir f2
cd f1
mkdir f
cd f
echo "First_Folder" >> file.txt
cd ..
echo "1" > file.txt
fallocate -l 10MB file.txt
echo "2" > file.txt
fallocate -l 10MB file.txt
echo "3" > file.txt
fallocate -l 10MB file.txt
echo "4" > file.txt
fallocate -l 10MB file.txt
cd ..
cd f2
mkdir f
cd f
echo "Second_Folder" >> file.txt
cd ..
echo "11" > file.txt
fallocate -l 10MB file.txt
echo "22" > file.txt
fallocate -l 10MB file.txt
echo "33" > file.txt
fallocate -l 10MB file.txt
echo "44" > file.txt
fallocate -l 10MB file.txt
cp -r "$HOME"/Buggy/fol1/f1 "$HOME"/Buggy/fol2
cp -r "$HOME"/Buggy/fol1/f2 "$HOME"/Buggy/fol2
rm -IR "$HOME"/Buggy/fol2/f1
mv "$HOME"/Buggy/fol2/f2 "$HOME"/Buggy/fol2/f1
cd "$HOME"
cat "$HOME"/Buggy/fol2/f1/f/file.txt >> results.txt # If I am not making an error in my analysis then the output should be "Second_Folder", but it is "First_Folder" instead.

fi

# to reproduce, the contents of this file need to be copied/pasted into the terminal

# up-to-date as of Sat 04 Sep 2021

Steps :

1) Open the terminal application and enter an "sh" shell with the command sh
2) Copy-paste the commands, type "y" followed by Enter when prompted.
3) Do Step 2 again
(note that you will exit sh and enter into a normal bash shell after step 3)
4) rm -rf "$HOME"/Buggy
5) Enter an "sh" shell again with the command sh
6) Repeat Step 2
results.txt ends with "First_Folder"

Now, do these:
1) rm -rf "$HOME"/Buggy
2) Run it as a script starting with #!/bin/sh
results.txt ends with "Second_Folder" now.

Now, do these:
1) rm -rf "$HOME"/Buggy
2) Run it as a script starting with #!/bin/bash
results.txt ends with "Second_Folder" now.

Now, do these:
1) Open the terminal application (with a bash shell)
2) rm -rf "$HOME"/Buggy
3) Copy-paste the commands, type "y" followed by Enter when prompted.
results.txt ends with "Second_Folder" now.

I think it has something to do with the error message being displayed if [ -d "$HOME"/Buggy ]

Removing that warning and replacing it with rm -rf "$HOME"/Buggy removes any discrepancies and consistently produces results.txt that ends with "Second_Folder".
Script without any discrepancies:

Code: Select all

# always produces "Second Folder"
if [ -d "$HOME"/"Buggy" ]
then
rm -rf "$HOME"/"Buggy"

else

cd "$HOME"
mkdir Buggy
cd Buggy
mkdir fol1
mkdir fol2
cd fol1
mkdir f1
mkdir f2
cd f1
mkdir f
cd f
echo "First_Folder" >> file.txt
cd ..
echo "1" > file.txt
fallocate -l 10MB file.txt
echo "2" > file.txt
fallocate -l 10MB file.txt
echo "3" > file.txt
fallocate -l 10MB file.txt
echo "4" > file.txt
fallocate -l 10MB file.txt
cd ..
cd f2
mkdir f
cd f
echo "Second_Folder" >> file.txt
cd ..
echo "11" > file.txt
fallocate -l 10MB file.txt
echo "22" > file.txt
fallocate -l 10MB file.txt
echo "33" > file.txt
fallocate -l 10MB file.txt
echo "44" > file.txt
fallocate -l 10MB file.txt
cp -r "$HOME"/Buggy/fol1/f1 "$HOME"/Buggy/fol2
cp -r "$HOME"/Buggy/fol1/f2 "$HOME"/Buggy/fol2
rm -IR "$HOME"/Buggy/fol2/f1
mv "$HOME"/Buggy/fol2/f2 "$HOME"/Buggy/fol2/f1
cd "$HOME"
cat "$HOME"/Buggy/fol2/f1/f/file.txt >> results.txt # If I am not making an error in my analysis then the output should be "Second_Folder"
fi

# to reproduce, the contents of this file need to be copied/pasted into the terminal

System Info:

Code: Select all

$ ls -lh /bin/sh
lrwxrwxrwx 1 root root 4 Sep  4 18:34 /bin/sh -> dash

$ apt list dash
Listing... Done
dash/stable,now 0.5.11+git20200708+dd9ef66-5 amd64 [installed]

$ bash --version
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)

Disclaimer: This code REMOVES the folder named "Buggy" inside your home directory.

[Termy]

I've rewritten and optimized the logic of your script, removing the constant `cd` calls, ran it numerous times, with and without `fallocate`, with both DASH ('/bin/sh') and BASH, but also always see `Second_Folder`.

BTW, this iteration removes the 'Buggy' directory once it's finished. If you have a directory by that name already, and don't wish it to be deleted, then do NOT run this iteration.

Code: Select all

#!/bin/sh

BuggyDir="$HOME/Buggy"
FileTXT_1="$BuggyDir/fol1/f1/f/file.txt"
FileTXT_2="$BuggyDir/fol1/f2/f/file.txt"
GroupFileTXT_1="$BuggyDir/fol1/fol1/file.txt"
GroupFileTXT_2="$BuggyDir/fol1/fol2/file.txt"

if ! [ -d "$BuggyDir" ]; then
	mkdir -p "${FileTXT_1%/*}" "${FileTXT_2%/*}"\
		"${GroupFileTXT_1%/*}" "${GroupFileTXT_2%/*}"\
		"$BuggyDir/fol2"

	for File in "First=$FileTXT_1" "Second=$FileTXT_2"; do
		printf '%s_Folder\n' "${File%%=*}" >> "${File#*=}"
	done

	for Number in 1 2 3 4; do
		printf '%d\n' $Number > "$GroupFileTXT_1"
		fallocate -l 10MB "$GroupFileTXT_1"
	done

	for Number in 11 22 33 44; do
		printf '%d\n' $Number > "$GroupFileTXT_2"
		fallocate -l 10MB "$GroupFileTXT_2"
	done

	cp -r "$BuggyDir"/fol1/f1 "$BuggyDir"/fol2
	cp -r "$BuggyDir"/fol1/f2 "$BuggyDir"/fol2
	rm -r "$BuggyDir"/fol2/f1
	mv "$BuggyDir"/fol2/f2 "$BuggyDir"/fol2/f1

	cat "$BuggyDir"/fol2/f1/f/file.txt # >> results.txt
	rm -r "$BuggyDir"
fi

I'm on a system of my own making, based on Ubuntu 18.04. My version of DASH (which '/bin/sh' uses) is 0.5.8-2.10 (for the package, at least), and my version of BASH is 4.4.20(1)-release.

If you'd like me to explain my changes to the above, let me know.

[rene]

Can consistently reproduce but Not A Bug.

The script should (and as a script does) produce Second_Folder, assuming that the rm -RI is answered affirmatively. Answered with anything other than a line starting with "y", "Y" or its internationalized variants, the folder "$HOME"/Buggy/fol2/f1 is not removed and the next mv "$HOME"/Buggy/fol2/f2 "$HOME"/Buggy/fol2/f1 is no longer a rename but in fact simply moves former folder into latter while leaving "$HOME"/Buggy/fol2/f1/f/file.txt untouched, i.e., saying "First_Folder".

As a script, when you answer "y" this is all you enter, but that reply is read from rm's stdin: when you paste the script into the terminal all after the final fi, all the commentary, is also being pasted in and available on stdin, and it to rm says "no".

A minimal example of this same effect is:

Code: Select all

$ touch foo && sleep 10 && rm -i foo && ls foo
nnnnnnnnnnnnrm: remove regular empty file 'foo'? y
foo

I.e., start hitting "n" (anything other than "y" in fact) during the sleep: the y which you hit after rm prompts is no longer relevant.

In the case of your script I consistently reproduce your issue with your script exactly as given, consistently do NOT reproduce with all the commentary deleted; with fi\n the actual last line. I trust that will be the same for you.

[EDIT] Thinking about this some more it's actually a bit more generic. That is, not specifically post-script commmentary would be the issue; just anything on stdin not yet consumed by the shell at the time rm -i runs. Anyways; that's the meat of it then: don't go read from stdin when at the same time you're providing the script itself on stdin.

[Termy]

I thought maybe OP had pasted it line-by-line, but if he or she did it all in one fell swoop, then ... what rene said. The same thing happens with a lot, if not every other similar prompt, such as apt-get(8)'s.

[linux_reader]

Thank you all so very much for all of your help.

rene is right; that is exactly what I was doing when running my script. (And now I know not to do that - thank you!)

I see that the script I wrote has not properly reproduced what I thought I'd observed via Raspbian's GUI over a week ago. I'm going to go back and try to go over the steps to reproduce it via the GUI (on Raspbian Buster), using a script for setup but using the GUI to reproduce the actual bug or its equivalent; then I'll try to see if I can reproduce this on a (debian-based) version of Linux Mint. I'll update once I have more information.

Thank you all again for your time, help, and patience.

[linux_reader]

Hi all, I'm back again.

I tried to reproduce what I'd previously observed on Raspbian by testing on the following OSes: Raspbian GNU/Linux 10 (buster) (fully updated), LMDE 4 (fresh install, no updates), LMDE 4 (fully updated), and Linux Mint 20.1 (Ulyssa) (fully updated).

The only OS on which I was able to reproduce anything similar to what I recall observing was Raspbian GNU/Linux 10 (buster). (For that OS, the folders of the newly created folder as displayed in the GUI resembled those of the previously deleted folder, despite the creation of sub-folders by the script, see script below. I speculate that it might have something to do with the prompt of "Do you want to move $file to trash can?", as Raspbian is the only one of the above OSes to offer that prompt that I noticed, but this may well be a red herring.)

As is, I'm not really sure where to go from here. With the rather charitable assumption that I haven't made another mistake, this doesn't appear to be a Linux Mint issue. If anyone wants to take a look at what I've found, that would be much appreciated, but if not, I understand. It seems rather off-topic for this forum.

In any case, thank you all again for your time, help, and patience.

The steps to reproduce what I observed on Raspbian GNU/Linux 10 (buster) are included below in the comments to the script.

Standard Disclaimer: I am new to Bash and I may well have errors in the script below. Please be careful and don't run it unless you understand what every statement in it is doing.


Script (the contents of my file entitled "Setup_Bug.sh"):

Code: Select all

# Please do not close any opened windows until the end of the test
# put Setup_Bug.sh on desktop
# Open Terminal Window
# Open GUI Window
# cd to Desktop for Terminal Window
# navigate to $Home in GUI Window
# in Terminal Window, please run "bash Setup_Bug.sh;"
# in the GUI Window, double-click on the "Buggy" folder, then double-click on "fol1" then move to Trash the folder named "f1", then right-click, click "Rename" and rename the folder "f2" to "f1"
# in the GUI Window, then go up a level to folder "Buggy", then go up a level to your "$HOME" folder
# in the GUI Window, right-click on the folder "Buggy" and Click "Move To Trash"; click "Yes" to confirm
# in the Terminal Window, please run "bash Setup_Bug.sh;"
# in the GUI Window, please double-click on the folder "Buggy" and then double-click on the folder "fol1".
# in the GUI Window, observe the folder "f1" without any "f2" folder


if [ -d "$HOME"/"Buggy" ]
then
echo "Not running test; please delete directory ~/Buggy; press any key to exit"
read
exit

else

cd "$HOME"
mkdir Buggy
cd Buggy
mkdir fol1
cd fol1
mkdir f1
mkdir f2
cd f1
mkdir f
cd f
echo "First_Folder" >> file0.txt
cd ..
echo "1" > file1.txt
fallocate -l 10MB file1.txt
echo "2" > file2.txt
fallocate -l 10MB file2.txt
echo "3" > file3.txt
fallocate -l 10MB file3.txt
echo "4" > file4.txt
fallocate -l 10MB file4.txt
cd ..
cd f2
mkdir f
cd f
echo "Second_Folder" >> file0.txt
cd ..
echo "11" > file1.txt
fallocate -l 10MB file1.txt
echo "22" > file2.txt
fallocate -l 10MB file2.txt
echo "33" > file3.txt
fallocate -l 10MB file3.txt
echo "44" > file4.txt
fallocate -l 10MB file4.txt
fi

[rene]

Paraphrasing without all the detail (which, don't get me wrong, may be necessary for what you are seeing / think to be seeing...)

1. Script creates ~/dir/sub/{subsub1,subsub2}
2. Graphical file manager in ~/dir/sub "moves to Trash" ~/dir/sub/subsub1
3. Graphical file manager in ~/dir/sub renames ~/dir/sub/subsub2 to ~/dir/sub/subsub1
4. Graphical file manager in ~ "moves to Trash" ~/dir

5. Script creates ~/dir/sub/{subsub1,subsub2} again
6. Graphical file manager in (newly navigated to) ~/dir/sub shows ~/dir/sub to not have a subsub2 subdirectory

If you simply hit F5 (normally...) to have the graphical file manage refresh its view as step 7 does subsub2 show up? I trust it definitely does if you close and reopen the graphical file manager?

In any case, this would then appear to be a bug in the Raspbian graphical file manager (but note that "newly navigated to" would be vital in classifying it such). If confirmed to show up after refresh I'd report this on a Raspbian forum/bugzilla somewhere, preferably one as dedicated to its graphical file manager as possible. I'd make very sure first that my above minimal/paraphrased version is not in fact all there's to it; that you need all the rest to reproduce.

[linux_reader]

Thank you again for your help!

rene said:
I'd make very sure first that my above minimal/paraphrased version is not in fact all there's to it; that you need all the rest to reproduce.

I appreciate your suggestion. In the future, when I post a script, I will try to pare it down to the minimum necessary to reproduce the issue. (I'm sorry; I should have done that earlier...) If it is okay, I'll get to that in my next post. (I still haven't fully reproduced what I originally observed, merely something similar under similar circumstances.) Thank you!

rene said:
If you simply hit F5 (normally...) to have the graphical file manage refresh its view as step 7 does subsub2 show up? I trust it definitely does if you close and reopen the graphical file manager?

Thanks for the suggestions! Yes, as you'd recommended, hitting F5 while in "fol1" and observing only "f1" being present does then bring up "f2".

Other observations of note:

• After being in "fol1" and observing only "f1" being present, navigating back to "$HOME" and pressing F5, then navigating back to "fol1" does not resolve the issue.

• After being in "fol1" and observing only "f1" being present, closing the window (as you'd recommended) and opening an new one and navigating to "fol1" does not resolve the issue.

• After being in "fol1" and observing only "f1" being present, Emptying the Trash through a different window causes the "fol1" window to close. When re-opened, the issue is resolved.

• After being in "fol1" and observing only "f1" being present, navigating back to "$HOME" and Emptying the Trash through a different window resolves the issue.

(Note: When I say "resolves the issue", I mean that "f2" displays normally in the "fol1" directory after navigating to "fol1".)

[rene]

Trying to simplify again this then seems to say that F5 refreshes only the currently displaying directory, and that closing and reopening the file-manager window also does not automatically even. Especially your third point may say that something more or less intentional is going on even if it turns out to not make sense in this situation; I'd furthermore discuss this with users and/or developers of your used graphical file-manager. Very little we here can now furthermore say.

[linux_reader]

Thank you; I'll look into setting up a Raspbian account, and I'll post a question there (trying to find an area that meets the recommended criteria, and revising the script appropriately beforehand).

Thank you all once again so very much for all your help!