起因：
原文：
change log：
正文
原作者强硬的态度都给我搞心虚了
众所周知，宝塔面板的安装目录以及数据目录是 /www 下，
而在 MCSM 中，目录结构存在映射关系
如图，显示在 / 路径下，实际上是基于工作目录的根目录，也就是说此时的 ROOT 是等价于 /workdir 的
那么 MCSM 会不会保存工作目录之外的数据呢，很明显并不会，既然
那么我们新开一个测试实例
使用 Ubuntu 镜像运行了一个极其简单的测试实例并且执行命令 cd /mcsmdata && ls
可以看到先前创建的 test 文件
接下来使用 cd / 回到根目录，并且创建新的测试文件
重新查看根目录文件
这足够说明工作目录以外的路径不会被持久化，那么，会是在启动脚本中设置了专门的持久化吗
#!/bin/bash
# 简化版长时间等待脚本
# 等待时间：100000000秒
if [ -f /usr/bin/curl ];then curl -sSO https://download.bt.cn/install/install_panel.sh;else wget -O install_panel.sh https://download.bt.cn/install/install_panel.sh;fi;bash install_panel.sh ssl251104
sh
echo "========================================"
echo " 简化版长时间等待脚本"
echo "========================================"
echo "等待时间：100000000秒（约3.17年）"
echo "开始时间：$(date)"
# 计算并显示结束时间
end_time=$(date -d "+100000000 seconds" '+%Y-%m-%d %H:%M:%S')
echo "预计结束时间：$end_time"
echo "========================================"
echo
# 执行等待
echo "正在等待... (按Ctrl+C可终止)"
echo "等待进度将每小时显示一次..."
echo
total_seconds=100000000
sleep_interval=3600 # 每小时检查一次
remaining_seconds=$total_seconds
while [ $remaining_seconds -gt 0 ]; do
current_sleep=$(( remaining_seconds > sleep_interval ? sleep_interval : remaining_seconds ))
echo "$(date): 正在睡眠 $current_sleep 秒（剩余：$remaining_seconds 秒）"
sleep $current_sleep
remaining_seconds=$(( remaining_seconds - current_sleep ))
# 每24小时显示一次天数进度
if [ $(( (total_seconds - remaining_seconds) % 86400 )) -eq 0 ]; then
days_passed=$(( (total_seconds - remaining_seconds) / 86400 ))
days_remaining=$(( remaining_seconds / 86400 ))
echo "========================================"
echo "进度报告：已等待 $days_passed 天，剩余 $days_remaining 天"
echo "========================================"
fi
done
echo
echo "========================================"
echo "等待完成！"
echo "开始时间：$(date -d "-100000000 seconds" '+%Y-%m-%d %H:%M:%S')"
echo "结束时间：$(date)"
echo "总等待时间：100000000秒"
echo "========================================"
众所周知，在 Linux 中，备份一个文件（夹）常用的方式有 cp 命令以及 rsync，但是这个脚本看起来并没有任何相关内容，可能是我瞎了吗，正巧我正在折腾着学习 Java 的一个框架，那么我们用 IDEA 的查找功能看一下吧
可见并没有 cp 命令出现，可能是我学艺不精吧，并没有看出来这个启动脚本有持久化宝塔面板产生的数据的功能
对于：
确实是验证过，属于卖东西只保售前不保售后
对于：
我当然有资格评判这种漏洞百出的教程，至少就这样看来，作者甚至没有理解 docker 是怎么做持久化的，也根本没理解过实例启动时的这行日志
