#1
|
|||
|
|||
BACKUP File linkcollector
In AppData\Local\JDownloader 2.0\cfg. I am wondering whether these are essential, and their purpose. I have 141 of these.
My cfg folder weights 5 Gb. I'd be great if i could save on some precious space, and even make JD 2 faster? Also considering converting my links into plain text. CTRL + A (select all), or CTRL + SHIFT (everything between A and B) > Right-Click > Properties > Show Download URLs > CTRL + A > CTRL + C > CTRL + V :D |
#2
|
||||
|
||||
Copying to plain text isn't going to assist you realistically. Remove unwanted items, every item uses memory on storage device/ram. The least items you have stored, the faster / more reactive the program will be.
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#3
|
|||
|
|||
Quote:
I have linkcollector17644.zip.backup to linkcollector27943.zip.backup (139 of these, dating as far back as 11/29/2019), then linkcollector27955 to linkcollector27960 (six of them), then linkcollector27961.zip.backup, linkcollector27962.zip.backup, and then linkcollector27963. What is their purpose? |
#4
|
||||
|
||||
JDownloader only uses the *.zip of the highest number for linkcollector/downloadlist.
the backups (*.zip.backup) are created by JDownloader when something goes wrong or preventative measure pre update? The latter would need to be confirmed by Appwork. They are used to prevent loss of lists. The *.zip auto purge with internal cleanup, where as the backups do not. I would say yes its safe for you to delete the backup items if you have no need for them. They are not required by the program for day to day use. If you want to wait for an offical response from Appwork, feel free.
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
25.05.2020, 14:38 |
pspzockerscene |
Message deleted by pspzockerscene.
Reason: My answer does not answer his question
|
#5
|
||||
|
||||
JDownloader auto creates .backup file in case JDownloader fails to load the list. With help of .backup you can later import/rescue the list again. For example list is too long and requires more memory than allowed, then loading will fails -> auto creates .backup file -> empty list. After changing allowed memory you can import that list again, see https://support.jdownloader.org/Know...nkgrabber-list
__________________
JD-Dev & Server-Admin |
#6
|
|||
|
|||
Thank you both for the explanations and the article by psp.
Would be great if i could restore every link i downloaded (and deleted) back into my downloadlist, but that's another subject. All ist klar kommissar! |
#7
|
|||
|
|||
I have another related question, if you fellows wouldn't mind clearing. Would it be safe to share the file with other people? That is to say, does it contain other identifiable information, aside from timestamps?
|
#8
|
||||
|
||||
@Beer
I would say its a bloated way to share links which contains components not necessary like save paths (safe?). I would recommend that you use DLC (download container) as it was designed to share links with the least required information (download password/extract password)
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#9
|
||||
|
||||
I agree with raztoki. although you can share those files you should remember that they can leak information like file/directory structure(for example username of os)
__________________
JD-Dev & Server-Admin |
#10
|
|||
|
|||
Thank you both for the assistance! I won't be using DLC container because we're talking about a massive number of links. Plain text will have to do then. Trusted people is alright, but for strangers the timestamps are way too much information.
|
#11
|
||||
|
||||
Trusted ppl, you can share the downloadList/linkcollectorXXX.zip just fine, but yes, plain links would be better
__________________
JD-Dev & Server-Admin |
Thread Tools | |
Display Modes | |
|
|