Upload remapping is a bit too enthousiastic

When a backup is restored to a database with a different name, there is a neat little piece of code in restorer.rb that attempts to fix this.

However, this renames ALL upload filenames, not just the ones that were extracted from the archive. If the database name occurs in an S3 path (which obviously does not change), it changes it as well, causing all images to fail loading.

3개의 좋아요

What do you think here @tgxworld?

Would changing this to include the trailing slash have helped?

DbHelper.remap("uploads/#{previous_db_name}/", "uploads/#{current_db_name}/")

That feels more correct in any case.

No - I’m talking about filenames like //discourse-cloud-file-uploads.s3.dualstack.us-west-2.amazonaws.com/standard11/uploads/DBNAME/original/1X/abcd.....jpg

So I think we’d need to exclude uploads starting with // or something like that.

We’re experiencing the pain of this quite abit while migrating local uploads to S3. Unfortunately, no amount of hacky remaps can fix this properly. What we’re currently working on at the moment is to remove/disallow upload links in Post#raw. The short upload url, ![test](upload://asdikajsdiasds.png), will be used as the public interface for access to uploads in raw.

Once that is done, we will only have to remap the urls in the uploads table and do a rebake of affected posts.

6개의 좋아요

“only” have to do a rebake… yes, on one hand I think it’s good to get rid of the hacky remaps, on the other hand it seems like the backup/restore and migrate from/to S3 processes are getting more and more complicated and hard.

See also a number of issues in Migrate_from_s3 problems which are kind of related but they’re not all covered by your proposed solution.

I do not think so, the moves will get significantly simpler. Walk the uploads table and upload all files to new s3 bucket, rebake and you are done.

They do though become more expensive computation wise cause a rebake is required.

This is a cost I think is worth bearing given we get a correct move at the end of the process. But, we have the flexibility of still doing database replace :roller_coaster: as we do today for the cooked column and post revisions if that is how we roll, the key change in the process is that we leave posts.raw alone and then have 0% of corruption there. posts.raw and posts_uploads auto generated map will always be stable.

4개의 좋아요

Ok - good point.

I think a significant improvement would be to walk the uploads table instead of posts (see the topic I linked above) and that would indeed leave the flexibility to replace in posts.cooked

이 문제 아직 남아 있나요 @sam?

로 마크다운에서 upload:// 링크를 사용하면 이 문제를 많이 해결해 줍니다. @gerhard가 수정했는지 확실하지 않아서, 복원 후 완전한 재번역을 큐에 넣을지 고민 중입니다. (그렇게 해야 한다고 생각합니다)

1개의 좋아요

상황에 따라 다릅니다. 최적화된 이미지가 백업에 포함되지 않는 경우(기본 설정)에는 업로드가 포함된 모든 게시물에 대해 재배킹을 수행합니다. 그렇지 않은 경우에는 리맵에만 의존합니다.

2개의 좋아요

무조건적으로 다시 베이킹하도록 변경하는 것이 더 안전할 것 같습니다.

2개의 좋아요

네, 방금 변경했습니다. 백업 및 복원 대규모 리팩토링에 포함될 예정입니다.

5개의 좋아요