# 如何将文件从旧的上传方案（default/XXX）迁移到新的方案（default/original/{1,2}X）？
**URL:** https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813
**Category:** Support
**Created:** [2019 年3 月 6 日 05:43 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813 "2019-03-06T05:43:02Z")
**Posts on this page:** 20
**Page:** 1
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 6 日 05:43 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/1 "2019-03-06T05:43:02Z")
I’ve been running a self-hosted Discourse site for about four and a half years now (since September 2014), and I just received a report of several broken image links on my site. After looking into the issue, I noticed that the paths to all of the offending images were in the format `uploads/default/XXX/`, where `XXX` is a three-digit number (e.g. `uploads/default/240/` and `uploads/default/247/`). Sure enough, the corresponding directories under `/var/discourse/shared/standalone/uploads/default/` were empty, but the problem was more extensive than I realized: almost _all_ the numbered directories under `/var/discourse/shared/standalone/uploads/default` appeared to be empty, as well!
Thankfully, it looks like most of the images had been moved to their corresponding folders in the “tombstone” directory (i.e. `/var/discourse/shared/standalone/uploads/tombstone/default/XXX/`) and should thus theoretically be recoverable by following @tgxworld’s [instructions](https://meta.discourse.org/t/my-forum-old-images-not-see/97123/22):
```plaintext
./launcher enter app
rails c
require_dependency "upload_recovery"
UploadRecovery.new.recover
```
The call to `UploadRecovery.new.recover` completed fairly quickly, but unfortunately it did _not_ restore the uploaded files to their original locations. Running `UploadRecovery.new(dry_run: true).recover` did not return any entries, either, so I was left with the impression that there isn’t a problem with the database (though I could be wrong!).
Anyway, after looking around a bit more I noticed that many of the newer files seemed to be uploaded under the `uploads/default/original/1X/` or `uploads/default/original/2X/` directories rather than `uploads/default/XXX/`. I wonder…could it just be that the canonical location for uploads has changed, and Discourse is now simply discarding anything that isn’t stored under `uploads/default/original/{1,2}X`?
For what it’s worth, all of the affected directories (i.e. `/var/discourse/shared/standalone/uploads/default/XXX/` and `/var/discourse/shared/standalone/uploads/tombstone/default/XXX/`) and their files appear to have the same “last-modified” timestamp—11:14 a.m. on January 18—which just so happens to be a few hours after I upgraded to v2.2.0.beta8 (though I couldn’t tell you the exact commit number). Interestingly enough, I don’t see this timestamp on any of the subdirectories of `uploads/default/original/{1,2}X/`.
In summary:
- Is there any reason that images stored in directories like `/var/discourse/shared/standalone/uploads/default/240/` would be automatically moved to the tombstone directory even if they are still being actively referenced by existing posts?
- Is it safe to just copy the missing images from `/var/discourse/shared/standalone/uploads/tombstone/default/XXX/` to `/var/discourse/shared/standalone/uploads/default/XXX/`, or is there another command I should run to accomplish this?
- If it _isn’t_ safe to copy the missing images and there _isn’t_ a command to accomplish this, how can I restore the images and/or update all the posts that reference them? (Should I migrate them to `uploads/default/original/{1,2}X/` somehow?)
Thanks!
---
### 作者：  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### 发布日期： [2019 年3 月 6 日 08:42 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/2 "2019-03-06T08:42:47Z")
Didn’t you run into this too @sam? Old installs have this issue.
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 6 日 14:23 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/4 "2019-03-06T14:23:57Z")
> [@kansaichris](#):
>
> Is there any reason that images stored in directories like `/var/discourse/shared/standalone/uploads/default/240/` would be automatically moved to the tombstone directory even if they are still being actively referenced by existing posts?
Looks like you have images that were not migrated to the new scheme.
Have you disabled the `migrate to new scheme` site setting?
> [@kansaichris](#):
>
> Is it safe to just copy the missing images from `/var/discourse/shared/standalone/uploads/tombstone/default/XXX/` to `/var/discourse/shared/standalone/uploads/default/XXX/` , or is there another command I should run to accomplish this?
It’s super safe, except it won’t last long 😉 If you don’t also update the database, then they’ll be moved back to the tombstone.
If you want to restore images, it’s better to use the `uploads:recover_from_tombstone` rake task.
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 7 日 00:04 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/5 "2019-03-07T00:04:27Z")
> [@zogstrip](#):
>
> Looks like you have images that were not migrated to the new scheme.
> Have you disabled the `migrate to new scheme` site setting?
Interesting…I couldn’t find a “migrate to new scheme” site setting via the web interface; I assume you’re talking about a setting that can only be accessed from a Rails console within the Docker container? i.e.
```plaintext
cd /var/discourse/
sudo ./launcher enter app
rails c
> SiteSetting.migrate_to_new_scheme
```
In that case, you’re right: for some reason `SiteSetting.migrate_to_new_scheme` was `false`, but—having never heard of that setting before—I certainly never disabled it myself! Should it have automatically been changed to `true` at some point?
> [@zogstrip](#):
>
> If you want to restore images, it’s better to use the `uploads:recover_from_tombstone` rake task.
Back [in July 2016](https://meta.discourse.org/t/old-image-uploads-become-broken-images/47236), it looks like you could fix the problem by following these steps:
```plaintext
# copy the "deleted" images from their to-be-deleted staging area
cd /var/discourse
./launcher enter app
rake uploads:recover_from_tombstone
# rebake to see that it doesn't happen again
rake posts:rebake
```
Then, [in October 2018](https://meta.discourse.org/t/old-image-uploads-become-broken-images/47236/33), @tgxworld said that those instructions were “stale” and that this is the new procedure:
```plaintext
./launcher enter app
rails c
require_dependency "upload_recovery"
UploadRecovery.new.recover
```
Now, just [three days ago](https://meta.discourse.org/t/uploaded-files-mysteriously-going-missing/53361/14), @sam suggested the following:
```plaintext
./launcher enter app
rails c
> SiteSetting.migrate_to_new_scheme = true
.... wait a day
rake posts:rebake
```
Which of these three methods is considered best practice?
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 7 日 11:16 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/6 "2019-03-07T11:16:09Z")
> [@kansaichris](#):
>
> I certainly never disabled it myself! Should it have automatically been changed to `true` at some point?
My bad, it’s a manual process.
> [@kansaichris](#):
>
> Which of these three methods is considered best practice?
So, the `UploadRecovery` class that @tgxworld built is an improvement over the `uploads:recover_from_tombstone`. They both do the same thing, only the `UploadRecovery` works for both the local and S3 storages, whereas the rake task only works for the local storage.
What @sam suggested won’t restore uploads that were put in the tombstone but is needed to be able to restore them.
So, here’s what you should do
```plaintext
./launcher enter app
rails c
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
```
You might need to execute the last line several times as this only migrate 50 uploads at a time.
Then, you can do
```plaintext
./launcher enter app
rake posts:rebake
rake uploads:recover
```
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 8 日 00:04 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/7 "2019-03-08T00:04:30Z")
> [@zogstrip](#):
>
> My bad, it’s a manual process.
Oh, okay. Does this mean that I will also need to disable the setting (i.e. run `SiteSetting.migrate_to_new_scheme = false`) after the migration process is complete?
> [@zogstrip](#):
>
> So, the `UploadRecovery` class that @tgxworld built is an improvement over the `uploads:recover_from_tombstone` . They both do the same thing, only the `UploadRecovery` works for both the local and S3 storages, whereas the rake task only works for the local storage.
Oh, neat! Thanks for the clarification. 👍
> [@zogstrip](#):
>
> What @sam suggested won’t restore uploads that were put in the tombstone but is needed to be able to restore them.
I _think_ I understand what you mean, but just to be clear: are you saying that changing the value of `SiteSetting.migrate_to_new_scheme` to `true` will tell Discourse to migrate all uploads to the new storage scheme, but it won’t touch any uploads that have already been placed in the tombstone directory (i.e. you need to move uploads out of the tombstone directory before they can be migrated)?
> [@zogstrip](#):
>
> So, we’re what you should do
>
> ```plaintext
> ./launcher enter app
> rails c
> SiteSetting.migrate_to_new_scheme = true
> Jobs::MigrateUploadScheme.new.execute(nil)
>
> ```
Hmm…do I need to run `Jobs::MigrateUploadScheme.new.execute(nil)` manually, or will it automatically be scheduled to run eventually (hence @sam’s [advice](https://meta.discourse.org/t/uploaded-files-mysteriously-going-missing/53361/14) to “wait a day”)?
In any event, I changed `SiteSetting.migrate_to_new_scheme` to `true` from the Rails console in my Discourse container yesterday. Interestingly enough, all of the numbered subdirectories under `/var/discourse/shared/standalone/uploads/default/` (e.g. `100`, `101`, `102`, `103`, `104`, and `105`) still appear to exist, and I found seven messages like the following in my error logs:
```plaintext
Job exception: undefined method `unlink' for #
```
Here’s a backtrace, in case you’re interested:
```plaintext
/var/www/discourse/app/models/optimized_image.rb:410:in `block in migrate_to_new_scheme'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activerecord-5.2.2/lib/active_record/relation/delegation.rb:71:in `each'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activerecord-5.2.2/lib/active_record/relation/delegation.rb:71:in `each'
/var/www/discourse/app/models/optimized_image.rb:367:in `migrate_to_new_scheme'
/var/www/discourse/app/jobs/scheduled/migrate_upload_scheme.rb:28:in `execute'
/var/www/discourse/app/jobs/base.rb:196:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rails_multisite-2.0.6/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:185:in `block in perform'
/var/www/discourse/app/jobs/base.rb:181:in `each'
/var/www/discourse/app/jobs/base.rb:181:in `perform'
/var/www/discourse/app/jobs/base.rb:243:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mini_scheduler-0.9.1/lib/mini_scheduler/manager.rb:82:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/mini_scheduler-0.9.1/lib/mini_scheduler/manager.rb:30:in `block in initialize'
```
At this point, would it still be safe for me to run the following commands or should I hold off until I have investigated the errors above?
```plaintext
cd /var/discourse/
sudo ./launcher enter app
rails c
> Jobs::MigrateUploadScheme.new.execute(nil)
[...]
> Jobs::MigrateUploadScheme.new.execute(nil)
> exit
rake posts:rebake
rake uploads:recover
```
Thanks again for all your help!
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 8 日 10:23 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/8 "2019-03-08T10:23:32Z")
> [@kansaichris](#):
>
> Does this mean that I will also need to disable the setting (i.e. run `SiteSetting.migrate_to_new_scheme = false` ) after the migration process is complete?
Won’t hurt if you leave it enabled.
> [@kansaichris](#):
>
> are you saying that changing the value of `SiteSetting.migrate_to_new_scheme` to `true` will tell Discourse to migrate all uploads to the new storage scheme, but it won’t touch any uploads that have already been placed in the tombstone directory?
Exactly 👌
> [@kansaichris](#):
>
> do I need to run `Jobs::MigrateUploadScheme.new.execute(nil)` manually, or will it automatically be scheduled to run eventually (hence @sam’s [advice](https://meta.discourse.org/t/uploaded-files-mysteriously-going-missing/53361/14) to “wait a day”)?
Both will work, I just suggested a way to fix it ASAP 😉
That job is scheduled every 10 minutes and only works when the `migrate_to_new_scheme` site setting is enabled.
> [@kansaichris](#):
>
> I found seven messages like the following in my error logs
Thanks, I [fixed](https://github.com/discourse/discourse/commit/ad12b2a23d50be3bbd7748145d3d487f25241a1d) that bug.
> [@kansaichris](#):
>
> At this point, would it still be safe for me to run the following commands
Yes, it’s safe. The error only happened for “optimized images” which you can always regenerate if you have the original 😉
---
### 作者：  [@hosna](https://meta.discourse.org/u/hosna)
#### 发布日期： [2019 年3 月 8 日 10:30 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/9 "2019-03-08T10:30:53Z")
> [@zogstrip](#):
>
> Looks like you have images that were not migrated to the new scheme.
Could you explain what is this? Should everyone do it? Or it should be done by old users? How should we know?
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 8 日 10:32 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/10 "2019-03-08T10:32:41Z")
> [@hosna](#):
>
> Should everyone do it? Or it should be done by old users?
Only very old (\> 4 years old) Discourse instances.
> [@hosna](#):
>
> How should we know?
You can check by doing
```plaintext
./launcher enter app
rails c
Upload.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/default/original/_X/%'").exists?
```
If this returns `true`, then you have images using the old scheme.
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 10 日 06:27 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/11 "2019-03-10T06:27:50Z")
Thanks for the clarification, @zogstrip! I just ran `rake posts:rebake` and `rake uploads:recover` in my Docker container, but so far it doesn’t look like any of my older uploads have been migrated to the new storage scheme. Of course, even though the `rake posts:rebake` command only took a few minutes to complete, I suppose it may have simply been queueing up rebake tasks—if so, will I have to wait a while for those to complete?
In the meantime, I’d like to be perfectly clear about what I’m trying to accomplish here. I have a lot of lines like the following in the Markdown source of older posts on my site:
```plaintext
```
(This will load the file saved at `/var/discourse/shared/standalone/uploads/default/247/232ac9c9d98b6458.jpg`.)
As far as I can tell, none of these image URLs have been changed to the following format, which can be found in the Markdown source of newer posts:
```plaintext
```
(This will load the file saved at `/var/discourse/shared/standalone/uploads/default/original/1X/6a8bd2193a5c4703620836334fd47bb4a54b9005.jpg`.)
It seems to me that there are a few things to be done here:
1. [Rehash](https://en.wikipedia.org/wiki/Hash_function) older uploads and store them under `uploads/default/original/1X/`.
2. Rewrite the Markdown source of older posts to reference the newly hashed files under `uploads/default/original/1X/`.
3. Regenerate the HTML versions of these older posts with the new image URLs.
I had thought that `rake posts:rebake` would rewrite these URLs in the Markdown source and regenerate the resulting HTML, and that either `rake uploads:recover` or `Jobs::MigrateUploadScheme.new.execute(nil)`—possibly both—would rehash and relocate the uploaded files, but perhaps I’m misunderstanding how the process works. If so, could you help me figure out what’s _really_ going on here? 😉
> [@zogstrip](#):
>
> You can check by doing
>
> ```plaintext
> ./launcher enter app
> rails c
> Upload.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/#{db}/original/_X/%'").exists?
>
> ```
>
> If this returns `true` , then you have images using the old scheme.
Interestingly enough, when I try to run this I encounter the following error:
```plaintext
NameError: undefined local variable or method `db' for main:Object
from (pry):2:in ` __pry__'
```
Am I missing something here?
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 11 日 10:47 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/12 "2019-03-11T10:47:18Z")
> [@kansaichris](#):
>
> Interestingly enough, when I try to run this I encounter the following error:
>
> ```plaintext
> NameError: undefined local variable or method `db' for main:Object
> from (pry):2:in ` __pry__'
>
> ```
>
> Am I missing something here?
It’s my bad, I copy-pasted directly from the code and forgot to remove the `db` variable interpolation.
The query should be
```ruby
Upload.by_users.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/default/original/_X/%'").exists?
```
As for your issue, I’ll have to dig into the code to see _exactly_ what’s going on.
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 11 日 11:15 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/13 "2019-03-11T11:15:33Z")
> [@zogstrip](#):
>
> It’s my bad, I copy-pasted directly from the code and forgot to remove the `db` variable interpolation.
Oh, no worries! In hindsight, I probably should have noticed that myself.
You know, it’s funny…I just ran the updated query and Discourse seems to think that I _don’t_ have any images using the old upload scheme:
```ruby
[1] pry(main)> Upload.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/default/original/_X/%'").exists?
=> false
```
Of course, that’s despite the fact that older posts still have a lot of lines like the following in their Markdown source:
```plaintext
```
¯\_(ツ)\_/¯
> [@zogstrip](#):
>
> As for your issue, I’ll have to dig into the code to see _exactly_ what’s going on.
Awesome, thanks! ✨
---
### 作者：  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### 发布日期： [2019 年3 月 17 日 23:03 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/14 "2019-03-17T23:03:19Z")
> [@zogstrip](#):
>
> If this returns `true` , then you have images using the old scheme.
But that’s true for new sites as well, because of stock images like:
```plaintext
=> [#,
```
So I think that test should be:
```
Upload.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/default/original/_X/%' and id>0").exists?
```
Best I can tell, running `Jobs::MigrateUploadScheme.new.execute(nil)` won’t fix them. And that [keeps `rake uploads:migrate_from_s3` from running](https://meta.discourse.org/t/migrate-to-s3-for-digital-ocean-spaces-woes/109662/24).
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年3 月 18 日 06:08 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/15 "2019-03-18T06:08:11Z")
Any updates on this, @zogstrip? Specifically…
> [@kansaichris](#):
>
> It seems to me that there are a few things to be done here:
>
> 1. [Rehash](https://en.wikipedia.org/wiki/Hash_function) older uploads and store them under `uploads/default/original/1X/` .
> 2. Rewrite the Markdown source of older posts to reference the newly hashed files under `uploads/default/original/1X/` .
> 3. Regenerate the HTML versions of these older posts with the new image URLs.
Does this sound correct to you, or am I misunderstanding how Discourse handles the migration of uploaded files?
Thanks!
---
### 作者：  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### 发布日期： [2019 年3 月 18 日 10:02 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/16 "2019-03-18T10:02:27Z")
> [@pfaffman](#):
>
> But that’s true for new sites as well, because of stock images like:
Yes, this was recently added by @tgxworld. I’ve fixed the query in my post and in the [`uploads:migrate_to_s3`](https://github.com/discourse/discourse/commit/9dbca41152e6f32aa45539ec50f499885b78edd8) rake task.
```ruby
Upload.by_users.where("url NOT LIKE '//%' AND url NOT LIKE '/uploads/default/original/_X/%'").exists?
```
> [@kansaichris](#):
>
> Any updates on this, @zogstrip? Specifically…
Didn’t get a chance to look at it just yet…
---
### 作者：  [@hosna](https://meta.discourse.org/u/hosna)
#### 发布日期： [2019 年3 月 22 日 05:04 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/17 "2019-03-22T05:04:38Z")
> [@zogstrip](#):
>
> Only very old (\> 4 years old) Discourse instances.
but I have installed discourse last year. However when I apply your code, It returned `true` .
I have these kinds of links:
> [@S3 migrations from/to minio problems](https://meta.discourse.org/t/s3-migrations-from-to-minio-problems/97333/50):
>
> btw I think there is still something wrong with my urls as @tgxworld mentions here.
---
### 作者：  [@watchmanmonitor](https://meta.discourse.org/u/watchmanmonitor)
#### 发布日期： [2019 年4 月 30 日 01:19 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/18 "2019-04-30T01:19:05Z")
The team has made some great progress with this:
> [@How to find any missing images?](https://meta.discourse.org/t/how-to-find-any-missing-images/115672/10):
>
> Upgrade to the latest version of Discourse and run the task rake posts:missing\_uploads again. The task itself will try to recover the missing old scheme uploads from local “uploads” and “tombstone” directories. At the end it will display the count of the uploads which are not found both in database and local storage.
---
### 作者：  [@kansaichris](https://meta.discourse.org/u/kansaichris)
#### 发布日期： [2019 年5 月 17 日 05:40 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/19 "2019-05-17T05:40:58Z")
Thanks, @watchmanmonitor! I’ll post a reply in that topic. 👍
---
### 作者：  [@system](https://meta.discourse.org/u/system)
#### 发布日期： [2022 年9 月 29 日 07:05 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/20 "2022-09-29T07:05:37Z")
---
### 作者：  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### 发布日期： [2022 年9 月 29 日 07:56 UTC](https://meta.discourse.org/t/how-can-i-migrate-files-from-the-old-upload-scheme-default-xxx-to-the-new-one-default-original-1-2-x/110813/21 "2022-09-29T07:56:04Z")