HomeSearchPrevious dayNext day

03:19:39HP_Archivist quits [Remote host closed the connection]
03:20:53HP_Archivist (HP_Archivist) joins
03:23:50AlsoHP_Archivist joins
03:27:40HP_Archivist quits [Ping timeout: 255 seconds]
03:40:57HP_Archivist (HP_Archivist) joins
03:43:25AlsoHP_Archivist quits [Ping timeout: 255 seconds]
06:35:35pabs quits [Read error: Connection reset by peer]
06:36:18pabs (pabs) joins
06:41:18pabs quits [Client Quit]
06:41:47pabs (pabs) joins
08:11:26BearFortress quits [Ping timeout: 256 seconds]
10:41:43BearFortress joins
12:04:16tzt quits [Ping timeout: 255 seconds]
12:08:14tzt (tzt) joins
12:25:58nulldata quits [Read error: Connection reset by peer]
12:28:50nulldata (nulldata) joins
13:30:08threedeeitguy39 quits [Quit: The Lounge - https://thelounge.chat]
13:53:09threedeeitguy39 (threedeeitguy) joins
14:04:06BearFortress_ joins
14:07:52BearFortress quits [Ping timeout: 256 seconds]
16:14:53<HP_Archivist>If I have source on files that I upload to a specific item, locally, and run ia download <identifier> for that specific item in the same local directory, will it recognize it's the same file as it usually does (based on length and date) and skip them? Or does it only recognize files in the way which were previously downloaded through the cli?
16:15:15<HP_Archivist>I could test this with a small file, but thought I would ask anyway
16:19:20<HP_Archivist>To be super clear, let me rephrase: If I have source files for an item that I previously uploaded stored locally, and I run the ia download <identifier> command for that same item in the same local directory, will the tool recognize that the files are the same (based on file length and date) and skip re-downloading them? Or does the ia tool only recognize files that were previously downloaded using the CLI?
16:41:21<KoalaBear>From my understanding, it checks for that, indeed based on the fileszie and the datettime
16:44:26<HP_Archivist>So it shouldn't make a difference if the file uploaded as previously downloaded from IA, or if it's just the original source file that still sits locally (if that makes sense)
16:44:38<HP_Archivist>was previously downloaded*
16:45:15<@JAA>I think IA uses the upload date for the mtime, not the original modification time (because there's no way to transmit that).
16:52:09<HP_Archivist>JAA: So it *does* make a difference? The reason I ask is - there's an item I'm downloading rn. But I have source on it. The files are ISOs each ~8GB in size. Rather than waste bandwidth (and time), I was thinking maybe I could copy/paste the source files into that directory that ia download command will be using and it would recognize/skip those
16:53:12<HP_Archivist>It seems like if I want to verify the accuracy of uploads and ensure local matches IA, and vice versa, I need to download per the mtime and not original mod time
16:53:45<HP_Archivist>Erm, or rather: use ia download etc
16:54:20<HP_Archivist>I'm just trying to avoid/cut down on bandwidth usage from IA servers and time spent doing so.
16:55:21<@JAA>HP_Archivist: It might. You could try using little-things/iasha1check or something equivalent to verify that the file contents are identical.
16:57:12<HP_Archivist>JAA: Oh right. You mentioned that the other day. Thanks for the reminder
18:05:52<@JAA>> sent 1,196 bytes received 108,977,612,515 bytes 1,320,852.72 bytes/sec
18:06:07<@JAA>Bloody hell, these backup server syncs are getting *worse*.
18:09:26<@JAA>> PHP Notice: Undefined index: acl in /var/cache/petabox/petabox/www/common/ListPolicy.inc on line 1043
18:09:29<@JAA>That sounds bad.
18:09:48<@JAA>Cc arkiver, task 4518238429
18:21:57threedeeitguy39 quits [Client Quit]
18:36:20OrIdow6 quits [Remote host closed the connection]
18:36:36OrIdow6 (OrIdow6) joins
18:41:58threedeeitguy39 (threedeeitguy) joins
19:57:09threedeeitguy39 quits [Client Quit]
20:06:14<katia>https://blog.archive.org/2024/09/04/internet-archive-responds-to-appellate-opinion/

HomeSearchPrevious dayNext day