Skip to content
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

Closed
joncameron opened this issue Apr 4, 2018 · 3 comments
Closed

Files In Dropbox Are Not Automatically Removed During Ingest #2903

joncameron opened this issue Apr 4, 2018 · 3 comments

Comments

@joncameron
Copy link
Contributor

joncameron commented Apr 4, 2018

Description

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.

@phuongdh
Copy link
Member

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.

@joncameron
Copy link
Contributor Author

The suggestion above is the probable solution to implement.

@carrickr
Copy link
Contributor

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

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

No branches or pull requests

7 participants