New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files In Dropbox Are Not Automatically Removed During Ingest #2903

joncameron opened this Issue Apr 4, 2018 · 3 comments


None yet
7 participants

joncameron commented Apr 4, 2018


When a file placed in an Avalon dropbox directory is ingested, it is never deleted from the original dropbox location. This results in files that are never moved or removed from the original dropbox location, and so these dropbox locations fill up with files that have already been ingested and processed, as well as creating confusion as to whether the files have actually been managed properly during ingest. This is also a regression from how Avalon used to deal with these files.

Possible Causes

@phuongdh investigated and thought that the issue may lie in the master_file model

Done Looks Like

If configured to do so, masterfiles are deleted after ingest from their dropbox directories.


This comment has been minimized.


phuongdh commented Apr 4, 2018

The problem is when media_path is configured, Avalon will always copy the original file there, then ingest the copy. Any MasterFileManagementJobs will be carried out on the copy, not the original, so the original will always remain.

A possible fix is to always delete the copy, and perform MasterFileManagementJobs against the original. We might need a new field on MasterFile object to track the copy's location.


This comment has been minimized.


joncameron commented Apr 12, 2018

The suggestion above is the probable solution to implement.

@joncameron joncameron added ready and removed Needs Refinement labels Apr 19, 2018

@carrickr carrickr self-assigned this Apr 26, 2018

@mcwhitaker mcwhitaker added current sprint and removed ready labels Apr 27, 2018


This comment has been minimized.


carrickr commented Apr 30, 2018

#2946 also might impact this, we should confirm before we delete

@bkeese bkeese added in progress and removed current sprint labels May 1, 2018

@bkeese bkeese self-assigned this May 1, 2018

@carrickr carrickr referenced this issue May 8, 2018


Feature/2903 #2956

@carrickr carrickr added In Review and removed in progress labels May 8, 2018

@joncameron joncameron added Sprint 152 and removed Sprint 151 labels May 11, 2018

@jlhardes jlhardes closed this May 25, 2018

@jlhardes jlhardes removed the In Review label May 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment