Wrong md5 checksum when reuploading modified source #1

New Issue

belka · 2023-12-16T21:12:54+01:00

belka commented

2023-12-16 21:12:54 +01:00

Consider a package where we download the source, extract the files, do some modifications, archive the files again and upload it to our storage.

The checksum in the updated .info file is the checksum from the original archive before the modifications.

Actually the download function should be probabliy rewritten for this case. We download a file and pipe it to tar -x directly (without saving the archive on disk). Then we do modifications and then do tar -c and pipe the output to 2 streams: file and hash function.

Consider a package where we download the source, extract the files, do some modifications, archive the files again and upload it to our storage. The checksum in the updated .info file is the checksum from the original archive before the modifications. Actually the download function should be probabliy rewritten for this case. We download a file and pipe it to `tar -x` directly (without saving the archive on disk). Then we do modifications and then do `tar -c` and pipe the output to 2 streams: file and hash function.

belka added the

Kind

bug

label 2023-12-16 21:12:54 +01:00

belka commented

2024-01-21 12:08:12 +01:00

Instead of tar the tar package can be used. The package reads the archives from the disk or uses lazy IO with lazy ByteString to perform extraction. I'll have to find out whether reading a HTTP request works lazily. Otherwise the easiest way is just to save the file on the drive as cache.

Call stack: reuploadWithTemplate -> downloadWithTemplate -> download.

Instead of `tar` the tar package can be used. The package reads the archives from the disk or uses lazy IO with lazy ByteString to perform extraction. I'll have to find out whether reading a HTTP request works lazily. Otherwise the easiest way is just to save the file on the drive as cache. Call stack: `reuploadWithTemplate` -> `downloadWithTemplate` -> `download`.

belka added the

Status

fixed

label 2024-01-24 14:36:30 +01:00

belka closed this issue

2024-01-24 14:36:32 +01:00

Sign in to join this conversation.