AlistGo/alist · error

delete failed: %s

Error message

delete failed: %s

What it means

GuangYaPan Delete error: /file/delete_file returned non-success msg, reported as 'delete failed: <backend msg>'. Deletion is asynchronous when the response carries a taskID; this error fires before that stage, at the initial request.

Source

Thrown at drivers/guangyapan/driver.go:310

func (d *GuangYaPan) Remove(ctx context.Context, obj model.Obj) error {
	if err := d.ensureAccessToken(ctx); err != nil {
		return err
	}

	fileID := strings.TrimSpace(obj.GetID())
	if fileID == "" {
		return errors.New("file id is empty")
	}

	var del deleteResp
	if err := d.postAPI(ctx, "/nd.bizuserres.s/v1/file/delete_file", map[string]any{
		"fileIds": []string{fileID},
	}, &del); err != nil {
		return err
	}
	if !strings.EqualFold(strings.TrimSpace(del.Msg), "success") {
		return fmt.Errorf("delete failed: %s", strings.TrimSpace(del.Msg))
	}

	taskID := strings.TrimSpace(del.Data.TaskID)
	if taskID == "" {
		// Some backends may apply deletion synchronously.
		return nil
	}
	return d.waitTaskDone(ctx, taskID)
}

func (d *GuangYaPan) Move(ctx context.Context, srcObj, dstDir model.Obj) error {
	if err := d.ensureAccessToken(ctx); err != nil {
		return err
	}

	fileID := strings.TrimSpace(srcObj.GetID())
	if fileID == "" {
		return errors.New("file id is empty")

View on GitHub (pinned to 843d9dc814)

Solutions

  1. Read the backend msg — it distinguishes not-exists from locked from permission
  2. Refresh the directory listing; if the file is gone, treat the delete as satisfied
  3. Retry once pending server tasks on that file finish
  4. Verify the account owns the file or has delete permission on the share
Defensive patterns

Strategy: try-catch

Try / catch

err := d.Remove(ctx, obj)
if err != nil && strings.HasPrefix(err.Error(), "delete failed") {
  msg := err.Error()
  if strings.Contains(msg, "exist") || strings.Contains(msg, "不存在") {
    // already gone: treat as success and refresh listing
  }
}

Prevention

When it happens

Trigger: Calling Remove where the backend rejects deletion outright: file already deleted, file locked by another task, permission level insufficient, or invalid fileIds — msg != success triggers the error before waitTaskDone runs.

Common situations: Deleting a file removed moments ago (double-click / duplicated requests); file engaged in an ongoing transfer; shared-to-me file without delete rights; stale cached listing.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/4e72a8aca8da63cf. Report an issue: GitHub.