Using UAAS and AzureFileSystemProvider. All our media is stored in azure blob storage. This works great for us except for the problem of syncing locally back to our workstations. We have over 20000 images in our blob/media nodes. This takes forever for us to sync locally now. The problem isn't the nodes on the Umbraco DB but the actual dowloading of the media locally. It also kind of sucks that it keeps doing that since it isn't using the media directory anyway.
Anyone have any ideas?
Mac
As far as I remember you don't have to actually sync those items on UaaS, so if you go into your courier.config file you can add an ignore for media items. I'm not entirely sure this works, but I think it should, in resources/ignore add:
Hey Sebastiaan.
Added but it still shows as downloading the *.jpg files. bummer. I was hoping that might have been a golden arrow. Thanks for your advice however.
MM
Does it actually download them though? Have a look in your media folder.. It might try but it "should" fail to do so since the deploy engine will try to pick them up from the local disk and it doesn't know about filesystemproviders.
My media files do not get restored locally when they've been uploaded to the cloud. Are you absolutely sure the files actually get stored in the cloud and not (also?) in your UaaS site in the media folder?
Maybe you're using a different FileSystem provider that might behave differently?
Sebastiaan... you are correct. Maybe there were some settings in my appdata folder in the models or TEMP that we causing it to repeatedly download. I just did another restore from dev to local after deleting the entire media folder and all files in appdata other than courier files. This time it did bypass downloading the nodes to the local workstation.
Thanks for keeping on it with me. We should probably update this related ticket that contradicts this behavior. http://issues.umbraco.org/issue/COU-421
bypass local synced media?
Using UAAS and AzureFileSystemProvider. All our media is stored in azure blob storage. This works great for us except for the problem of syncing locally back to our workstations. We have over 20000 images in our blob/media nodes. This takes forever for us to sync locally now. The problem isn't the nodes on the Umbraco DB but the actual dowloading of the media locally. It also kind of sucks that it keeps doing that since it isn't using the media directory anyway. Anyone have any ideas? Mac
As far as I remember you don't have to actually sync those items on UaaS, so if you go into your courier.config file you can add an ignore for media items. I'm not entirely sure this works, but I think it should, in
resources/ignoreadd:Hey Sebastiaan. Added but it still shows as downloading the *.jpg files. bummer. I was hoping that might have been a golden arrow. Thanks for your advice however. MM
Does it actually download them though? Have a look in your media folder.. It might try but it "should" fail to do so since the deploy engine will try to pick them up from the local disk and it doesn't know about filesystemproviders.
Yes it actually downloads the images. The media folder has a structure of node/*.jpg. I can see images that I uploaded to dev synced to my media.
I've just tested this scenario with: https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure/
My media files do not get restored locally when they've been uploaded to the cloud. Are you absolutely sure the files actually get stored in the cloud and not (also?) in your UaaS site in the media folder?
Maybe you're using a different FileSystem provider that might behave differently?
Sebastiaan... you are correct. Maybe there were some settings in my appdata folder in the models or TEMP that we causing it to repeatedly download. I just did another restore from dev to local after deleting the entire media folder and all files in appdata other than courier files. This time it did bypass downloading the nodes to the local workstation. Thanks for keeping on it with me. We should probably update this related ticket that contradicts this behavior. http://issues.umbraco.org/issue/COU-421
is working on a reply...