[Bug] When downloading Big files/videos, constantly get ERRORS

[harshbhardwaj77]

Describe the bug

When downloading Big files/videos, constantly get ERRORS like this --

Adda(Q):21445 -> C:\tdl\download\Q_21445_train-003.4K.mp4 error: post file: rename file: rename C:\tdl\download\Q_21445_train-003.4K.mp4.tmp C:\tdl\download\Q_21445_train-003.4K.mp4: The process cannot access the file because it is being used by another process

This usually happens for videos/files ABOVE 100MB. This write/rename issue happens a LOT & because of this File starts to download again from the start. Which is a waste of time.

I hope you guys can fix this Bug

To Reproduce

tdl -n Q dl -f Q.json --pool 2 -t 4 -l 2 --delay 20s -d C:/tdl/download --group --template "{{ .DialogID }}{{ .MessageID }}{{ filenamify .FileName }}" --skip-same --continue --takeout --debug --ntp pool.ntp.org --reconnect-timeout 3m

Expected behavior

Large files should just be downloaded without this write/rename issue which happpens when the file is 100% complete while it is getting saved this ERROR shows up. This should not happen.

Version

Version: 0.20.1
Commit: 742da1b
Date: 2025-12-14T16:19:18Z

go1.23.10 windows/amd64

Which OS are you running tdl on?

Windows

Additional context

No response

[devmanbr]

I spent the entire last week banging my head trying to solve this problem.

I created a script to carry out the downloads in a more automated way, and I constantly saw it "choke" on the same issue. However, unlike your case, it didn't only occur with large files but also with images of just a few KBs.

I started testing 1001 different solutions, tried to control the process in various ways, scoured forums and topics, debugged nearly to the point of losing my mind, and only after all that did I start putting the pieces of the puzzle together: the problem is not necessarily the TDL, but just its interaction with the file system (or something close to that).

From what I've seen, this problem is restricted to Windows.
The reason lies in the difference between how the kernel handles data access. In Windows, we have what is called mandatory locking: when a process opens a file, the operating system often prevents any other process (or even the same process, under certain conditions) from deleting, moving, or writing to it until the first one closes the connection. If your script tries to rename a file while the download process still holds its handle, Windows immediately blocks the operation. This practically doesn't exist in Linux.

Since possibly the project developers, like @iyear, don't use Windows, this problem tends to go unnoticed.

All that is necessary is to fix this 'race condition' to resolve it.

[devmanbr]

I'm seriously considering sponsoring the project, but I really need this problem solved. Without it, I can't consider the project "the solution," since I haven't been able to download a single channel because of this issue.