Issue Type / 问题类型
Bug / 缺陷
kkFileView Version / kkFileView 版本
5.0.2
Deployment Mode / 部署方式
docker built from source via the official Dockerfile
Environment / 环境信息
Description
Converted preview artifacts under file.dir are named after the source file's basename only — no source path and no hash of the full URL is included. Because of this, two different files from different paths (or different storage backends) that happen to share the same filename write their converted output to the same physical path, overwriting each other.
Steps to Reproduce / 复现步骤
- Prepare two files with the same name but different content, served from two different URLs, e.g.
.../pathA/test.docx (content "AAAA") and .../pathB/test.docx (content "BBBB").
- Preview
.../pathA/test.docx via onlinePreview → confirms "AAAA".
- Preview
.../pathB/test.docx → confirms "BBBB".
- Preview
.../pathA/test.docx again.
Expected Result / 期望结果
Still shows "AAAA".
Actual Result / 实际结果
Shows "BBBB" — pathA's cached entry now serves pathB's converted file, because both conversions wrote to the same output filename on disk.
Suspected cause
The cache lookup appears to be keyed by the full request URL, but the converted file's on-disk name is derived only from the URL's last path segment (the original filename), so the URL-based cache key and the physical output path are not consistently tied together. Any two source URLs with the same trailing filename will collide.
Suggested fix
Derive the on-disk output filename from a hash (e.g. short MD5/SHA1) of the full source URL, or otherwise namespace the output path per source URL, instead of using only the trailing filename segment. This preserves human-readable names while guaranteeing uniqueness across paths.
This is a real concern for any deployment that fronts multiple storage backends/paths with overlapping filenames (e.g. behind AList, Alfresco, or similar multi-tenant file browsers), since it can silently serve one user's document content to another.
Logs & Screenshots / 日志与截图
Sample File / 样例文件（可选）
No response
Checklist / 提交前检查
Issue Type / 问题类型
Bug / 缺陷
kkFileView Version / kkFileView 版本
5.0.2
Deployment Mode / 部署方式
docker built from source via the official Dockerfile
Environment / 环境信息
Description
Converted preview artifacts under
file.dirare named after the source file's basename only — no source path and no hash of the full URL is included. Because of this, two different files from different paths (or different storage backends) that happen to share the same filename write their converted output to the same physical path, overwriting each other.Steps to Reproduce / 复现步骤
.../pathA/test.docx(content "AAAA") and.../pathB/test.docx(content "BBBB")..../pathA/test.docxviaonlinePreview→ confirms "AAAA"..../pathB/test.docx→ confirms "BBBB"..../pathA/test.docxagain.Expected Result / 期望结果
Still shows "AAAA".
Actual Result / 实际结果
Shows "BBBB" — pathA's cached entry now serves pathB's converted file, because both conversions wrote to the same output filename on disk.
Suspected cause
The cache lookup appears to be keyed by the full request URL, but the converted file's on-disk name is derived only from the URL's last path segment (the original filename), so the URL-based cache key and the physical output path are not consistently tied together. Any two source URLs with the same trailing filename will collide.
Suggested fix
Derive the on-disk output filename from a hash (e.g. short MD5/SHA1) of the full source URL, or otherwise namespace the output path per source URL, instead of using only the trailing filename segment. This preserves human-readable names while guaranteeing uniqueness across paths.
This is a real concern for any deployment that fronts multiple storage backends/paths with overlapping filenames (e.g. behind AList, Alfresco, or similar multi-tenant file browsers), since it can silently serve one user's document content to another.
Logs & Screenshots / 日志与截图
Sample File / 样例文件（可选）
No response
Checklist / 提交前检查