How does CFS cleanup affect my content (and related questions)?

The documentation has this to say about CFS cleanups.

Cleaning Up Temporary Files
Telligent Community does eventually clean up old file upload contexts by deleting the id; this means the files will stay in any locations it was used on the site, but the context id will no longer be usable in future requests. The timing of this cleanup is configurable in MultipleFileUploadCleanupJob.

Does this mean that the URL returned when you store data in CFS is only available for a certain time period?

To be specific, I did this...

  • POSTed an image to CFS, it returned a URL http : // xyz.telligenthosting.net/cfs-file/__key/.../embeddedimage
  • I use that URL in an image tag <img src="https : //xyz.telligenthosting.net/cfs-file/__key/.../embeddedimage"/>
  • Two days later the image was reported to be broken.

In my example, is the image broken due to the cleanup?

Am I correct in that the proper way to do this would be to embed the image using the [view] syntax?

Am I correct in thinking that the CFS cleanup will delete any temporary image that isn't explicitly referenced via a [view] ?

Thanks.

  • POSTing to CFS is an interim step to using the returned link for creating other content - for instance, changing a user avatar or embedding an image in a post. See this link for more details: community.telligent.com/.../uploading-files

    The interim link will be removed after a time, but the link and file created in the other content will stay.

  • Unfortunately this doesn't appear to be working as advertised.

    Yesterday I performed these steps:

    • Uploaded file to CFS via REST, it returned the URL "/cfs-file/__key/CommunityServer-Components-MultipleUploadFileManager/54e8cd65_2D00_8d25_2D00_4f86_2D00_adc4_2D00_f2387ae46206-2109-complete/embedded_2E00_.jpg"
    • Created a new Forum Thread via REST, within the content I included the code "View:/cfs-file/__key/CommunityServer-Components-MultipleUploadFileManager/54e8cd65_2D00_8d25_2D00_4f86_2D00_adc4_2D00_f2387ae46206-2109-complete/embedded_2E00_.jpg:223:335" (brackets omitted here because it causes issues with the editor).

    And today, the image is gone.

    I created a widget this morning that calls  $core_v2_forumThread.Get(...).Body('raw') to see what is currently stored and it still shows the same View URL as it did when I created the content (I thought it was supposed to move the content and change the URL).

    Any ideas? 

  • I am able to reproduce this behavior by doing the following:

    • Upload image via the CFS endpoint (/api.ashx/v2/cfs/temporary.json).  In the response is a "DownloadUrl" value that looks like "{HOST} / cfs-file / __key/CommunityServer-Components-MultipleUploadFileManager / {UNIQUEID}-complete / test.png".
    • Create a new Forum Thread using the REST endpoint /api.ashx/v2/forums/{forumid}/threads.json.  In the "Body" param include the uploaded image using the syntax "View:{URL}:{WIDTH}:{HEIGHT}" (in square brackets)

    At this point you can go into Telligent to view the content with the inline image.  On inspecting the content, the image path didn't change, it still points to the temporary area.

    Next force an image cleanup:

    • Edit the Job "Multiple File Upload Cleanup", set the option "Expire Connection After" to 0, and change the schedule to have it run every 2 minutes.
    • Wait a few minutes.

    At this point when you view the content the images have disappeared.

    Ultimately I think the question is how do you force a CSF file out of the temporary space and into the permanent space?

  • While it shouldn't be so sensitive, our embeds would use a ~/ prefixed URL. Since you have a test case setup, could you try the same scenario with the URL starting ~/cfs-file/... instead of just /cfs-file/? If that works, I'll log a bug to handle the unprefixed URL. If it doesn't, there's something else going on here.

  • Thanks it appears the problem was that the image was being uploaded by a different user than the content.  I performed quite a few tests and found that both / and ~/ both work.

    Thanks for the help.

  • Ah, okay. Yes. Staged files are user-specific. Thanks for following up.