The validator deletes .../repository/CACHEDIR.TAG on upgrades

[rfc1036]

The Debian package creates /var/lib/fort/CACHEDIR.TAG to prevent backup programs from wasting time and storage storing generations of cached data which could be trivially downloaded again.

Starting with 1.6.0, fort on upgrades deletes the whole directory and the CACHEDIR.TAG file too:

invalid_cache:
       pr_op_info("The cache appears to have been built by a different version of Fort. I'm going to clear it, just to be safe.");
       file_rm_rf(config_get_local_repository());

Possible solutions:

• have fort delete only the files/directories that it knows it has created
• have fort itself create the CACHEDIR.TAG file when initializing the repository
• move the repository to /var/cache/fort/ (but would this work at all? Programs must cope with files in /var/cache/ disappearing at any time)
• ?

[lukastribus]

have fort itself create the CACHEDIR.TAG file when initializing the repository

I think this would be the most straightforward approach.

[ydahhrk]

Interesting. I didn't know about this file, and reading up on it, I also agree with

• have fort itself create the CACHEDIR.TAG file when initializing the repository

to provide the solution even outside of Debian.

I'll add it today.

---

Starting with 1.6.0, fort on upgrades deletes the whole directory and the CACHEDIR.TAG file too:

Actually, this bug is specific to the issue103 branch. The code does not exist in 1.6.0.

---

I don't know if this is viable, but if you run into this situation again (with a different package), I would suggest a fourth option:

• Prevent the program (or rather, service) from having write permissions over CACHEDIR.TAG.

Since the file was being managed by the package, not the program.

[ydahhrk]

New branch.

[ydahhrk]

Sorry; I'd left a bug that prevented Fort from creating CACHEDIR.TAG when it flushed the cache. I just pushed the patch to both issue104 and main.