td
td copied to clipboard
Ability to set custom path for DownloadFile & InputFileGenerated
@Nullable String path
in DownloadFile
would allow implementing features such as:
- Download folder setting (without need in restarting & moving all already downloaded files to a new directory manually by client)
- Client would be able to control directories' names
- Save As...
Probably more.
@Nullable String path
in InputFileGenerated
would, for example, allow saving generated media directly to the gallery.
Currently clients have two options: copying generated file after generation finish (which would double disk space usage per file) & moving generated file after generation finish (which probably? would waste data usage, if user tries to upload same generated file again later).
It will make impossible for TDLib to manage these files as part of application cache. They will never be deleted by optimizeStorage and will not be returned by getStorageStatistics.
It also can introduce a lot of security vulnerabilities, allowing to rewrite critical for application files and exploiting some file system/file access vulnerabilities.
The fact that they won't be able to be detected by storage statistics is not so critical, as user will be able to remove such files manually from gallery.
However, why it's not possible to add something like String[] additionalScanFolders
to storage statistics / optimization requests? The fact that such files won't be removed by automatic check (e.g. Keep Media setting) is in fact good, as they should not be deleted.
Also I didn't understand the part about vulnerabilities. Such option is supposed to be used only for media, which are usually not opened by clients themselves (except for photos).
In case of secret chats / thumbnails / other stuff TDLib could easily ignore this parameter for security reasons.
Do you expect that TDLib will clean user's gallery if it is specified in additionalScanFolders
? It's too dangerous to delete any file outside TDLib's file directory, because the file may be needed by user. It makes additionalScanFolders
parameter useless.
There are a lot of vulnerabilities, which can allow intruder to rewrite system file/app database if it can choose name of a file to create in the file system. TDLib protects from such vulnerabilities by restricting list of folders in which files can be created and by heavily limiting number of allowed characters in file names. There is a cleanFileName
synchronous method, which allows application to repeat TDLib's logic, but it is yet hard to use right.
No, I don't, but there are many other types of files.
It's not necessarily should allow choosing output file name, if it would allow just choosing custom folder (controlled by client itself) it would be enough to implement many requested features, such as saving downloaded photos and videos to gallery without duplicating them / exposing all other types of media to the public directory.
Any ideas how to implement downloading documents into custom location like "Downloads"?
Any ideas how to implement downloading documents into custom location like "Downloads"?
Client might create hardlink (in some custom dir) to the downloaded file, so when tdlib optimizes storage the file won’t be removed from filesystem
Drawback of hardlink is that in must belong to same disk volume
Creating a hardlink or copying the file after it was downloaded is a good idea for now. Currently, there is no way to ask TDLib to create a file outside of database/files directory.
hi Use TdApi.DownloadFile to download images to directory photos, Under what circumstances are images in the directory deleted,Is it the capacity of photos or the number of images,Is there any way to keep the image from being deleted
@laitianxu If you pass setTdlibParameters.useStorageOptimizer=false
and never explicitly call optimizeStorage
, then files are deleted only when the corresponding message is permanently deleted.
hardlink
where is database/files i check in my phone and Device File Explorer but I didn't find the download location