不能，watchdog仅监听本地文件系统；需先用ftplib等同步FTP文件到本地目录，再用FileSystemEventHandler监听modified事件，配合文件大小稳定判断和解密前校验实现可靠解密。
watchdog 能监听 FTP 目录吗？不能，得换思路
watchdog 本身只监听本地文件系统事件，对 FTP 服务器上的目录完全无感知。如果你把 FTP 客户端挂载成本地路径（比如用 curlftpfs 或 lftp mount），watchdog 才可能生效——但这类挂载不稳定、不支持 inotify、容易掉连接，生产环境基本不可靠。
更可行的做法是：用 watchdog 监听你本地已同步下来的 FTP 下载目录（比如 /data/incoming），而 FTP 同步本身交给独立任务完成。
- FTP 同步推荐用
ftplib+ 定时轮询（简单可控），或pyftpdlib+ 主动推送（需服务端配合） - 同步逻辑必须记录已处理文件名或时间戳（如写入
.sync_state.json），避免重复解密 - watchdog 只负责「本地目录有新文件落地」这一瞬间的触发，不参与网络通信
用 FileSystemEventHandler 捕获新文件落地事件
重点不是监听“创建”，而是监听“写入完成”。FTP 客户端（如 lftp）上传时往往先建空文件再覆盖写入，直接响应 created 事件会拿到未写完的文件，导致解密失败。
稳妥做法是监听 modified 事件，并加一层文件大小稳定判断：
from watchdog.events import FileSystemEventHandler
import time
<p>class DecryptHandler(FileSystemEventHandler):
def <strong>init</strong>(self, decrypt_func):
self.decrypt_func = decrypt_func
self._last_size = {}</p><pre class="brush:php;toolbar:false;">def on_modified(self, event):
if event.is_directory:
return
path = event.src_path
try:
size = os.path.getsize(path)
if path not in self._last_size or size != self._last_size[path]:
self._last_size[path] = size
time.sleep(0.5) # 等待写入缓冲落盘
if os.path.getsize(path) == size: # 大小没再变，认为就绪
self.decrypt_func(path)
except (OSError, FileNotFoundError):
pass
- 不要依赖
created或moved_to—— FTP 工具行为不统一，moved_to在某些挂载方式下根本不会触发 -
time.sleep(0.5)是权宜之计；更健壮方案是用inotifywait --monitor --format '%w%f' --event moved_to,close_write配合 subprocess - 务必加
try/except，防止临时文件（如.file.part）引发异常中断监听
解密函数要防御性处理文件状态
解密前必须确认文件可读、未被其他进程占用、且扩展名符合预期（比如只处理 .enc 或 .gpg）。否则 watchdog 线程卡住会影响后续事件分发。
示例中解密函数应返回布尔值表示是否成功，便于日志和告警：
def decrypt_file(filepath):
if not filepath.endswith(('.enc', '.gpg')):
return False
try:
with open(filepath, 'rb') as f:
# 假设用 cryptography 库 AES-GCM 解密
# 注意：密钥不能硬编码，应从环境变量或密钥管理服务获取
decrypted = decrypt_aes_gcm(f.read(), key=os.environ[b'APP_DECRYPT_KEY'])
outpath = filepath.rsplit('.', 1)[0]
with open(outpath, 'wb') as f:
f.write(decrypted)
os.remove(filepath) # 成功后才删源文件
return True
except Exception as e:
print(f"Decrypt failed for {filepath}: {e}")
return False
- 永远先写解密结果到新路径，再删原文件 —— 防止解密中途失败导致数据丢失
- 密钥绝不能出现在代码里；
os.environ也需确保启动脚本已正确加载，否则会抛KeyError - 注意二进制读写模式（
'rb'/'wb'），文本模式会破坏加密数据
watchdog 启动时容易忽略的权限与守护问题
在 Linux 上以 systemd 服务运行时，常见问题不是代码逻辑，而是上下文缺失：
- 用户权限：运行 watchdog 的用户必须对监控目录有
r+x权限，对解密输出目录有wx权限；FTP 同步脚本若用另一用户执行，可能造成文件属主不一致 - 工作目录：watchdog 不自动切换到监控路径，
os.chdir()必须显式调用，否则相对路径配置（如密钥路径）会失效 - 日志重定向：默认 stdout/stderr 会丢进 systemd 的 journal，但错误堆栈若没捕获，只会看到 “Process exited” —— 建议用
logging.basicConfig(filename='/var/log/watchdog-decrypt.log') - 不要用
observer.start(); observer.join()写法跑在后台 —— 一旦崩溃，systemd 不知道它挂了；应包装成循环+健康检查
最易被忽略的一点：FTP 同步和 watchdog 解密必须串行化。如果同步脚本每次把 10 个文件一股脑丢进目录，而解密函数耗时较长，watchdog 可能并发调用多次，导致同一文件被反复尝试解密甚至删错。加个简单的文件锁（flock）比自己实现队列更可靠。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
