[Bug] File manager may download stale content after a file is replaced at the same path

[LetTTGACO]

1Panel Version

v1.10.34-lts

Problem Description

The file manager may download a stale version of a file after the file has been replaced or modified without changing its path or filename.

The file list displays the current size and modification time correctly, but clicking Download returns the contents of an older version. Repeating the download returns the same stale binary.

This is a data-integrity issue because a user may unknowingly restore or re-upload the outdated file.

Steps to Reproduce

1. Download a file from the 1Panel file manager.
2. Replace or modify that file while keeping the same path and filename.
3. Refresh the file manager.
4. Confirm that the list shows the new file size and modification time.
5. Click Download again.
6. Compare the downloaded file with the current file on the server.

Actual Result

The file list showed the current file as 3.74 KB, but the downloaded file was an older 2128-byte version.

Current server file:

• Size: 3834 bytes
• SHA-256: 7770b5a4330b054a089362bd580a15257f56f31674217905d3605acac6bb5e40

The same file inside the running Docker container had the identical size and hash.

Downloaded file:

• Size: 2128 bytes
• SHA-256: 295379771e2036ee1d14efdb43bd9020e3595997b7a46d3ce508e2b1c117506d

No 2128-byte copy of this file existed under the 1Panel application directory on the server at the time of verification.

Expected Result

The download endpoint should return the current contents of the selected file. Arbitrary server-file downloads should not be served from a stale browser or intermediary cache.

Technical Context

In v1.10.34-lts, the frontend opens a stable GET URL based on the file path:

/api/v2/files/download?operateNode=<node>&path=<file-path>

The backend serves the file using http.ServeContent without an explicit Cache-Control: no-store policy. The frontend URL also contains no cache-busting value tied to the current file version.

Relevant source:

• Frontend:

  1Panel/frontend/src/utils/util.ts

  Lines 609 to 613 in 2c92226

  	export function downloadFile(filePath: string, currentNode: string) {
  	let url = `${import.meta.env.VITE_API_URL as string}/files/download?operateNode=${currentNode}&`;
  	let path = encodeURIComponent(filePath);
  	window.open(url + 'path=' + path, '_blank');
  	}

• Backend:

  1Panel/agent/app/api/v2/file.go

  Lines 545 to 562 in 2c92226

  	// @Router /files/download [get]
  	func (b *BaseApi) Download(c *gin.Context) {
  	filePath := c.Query("path")
  	file, err := os.Open(filePath)
  	if err != nil {
  	helper.InternalServer(c, err)
  	return
  	}
  	defer file.Close()
  	info, err := file.Stat()
  	if err != nil {
  	helper.InternalServer(c, err)
  	return
  	}
  	c.Header("Content-Length", strconv.FormatInt(info.Size(), 10))
  	c.Header("Content-Disposition", "attachment; filename*=utf-8''"+url.PathEscape(info.Name()))
  	http.ServeContent(c.Writer, c.Request, info.Name(), info.ModTime(), file)
  	}

Possible fixes:

• Set Cache-Control: no-store on file-download responses.
• Add a cache-busting or file-version parameter to the generated download URL.
• Add a regression test that replaces a file at the same path and downloads it again.

Additional Information

A screenshot showing the current file size and modification time in the file manager will be added separately. The affected binary is not attached because it may contain private server configuration.

[wanghe-fit2cloud]

感谢反馈，建议参考文档 将 1Panel 从 V1 迁移至 V2，然后确认该问题是否仍然存在。