Open brucejo75 opened 8 years ago
Hi see my comments over there, the behavior you describe is expected w.r.t. file-collection. It is the sample app that is producing what you are observing.
Hi, what do you think of adding an options argument to fc.remove
?
something like:
fc.remove(file, undefined, { removeIncompleteData: true })
Then fc.remove
could take out the main file link and all chunks from the incomplete file.
I appended the options to be backward compatible...
I would jump on this and send you a pull request, but I do not understand coffee and I have not built a package yet. I forked the project, but it looks like there are no build scripts included in meteor-file-collection?
FYI, this general issue (incomplete uploads) has come up before: https://github.com/vsivsi/meteor-file-collection/issues/77
Having a day to think about this, I think that fc.remove()
should always clean-up any associated temporary files. There is no practical way to "resume" uploading to a deleted file, so this should be the default behavior (no special option required).
However, implementing it elegantly may be tricky because the server-side resumable.js support is about 98% separate from file-collection, and the goal going forward is to make that 100% so that it is easy to plug-in support for other chunked uploading solutions. See for example:
https://github.com/vsivsi/meteor-file-collection/pull/107 https://github.com/vsivsi/meteor-file-collection/issues/102
Anyway, this is a problem that any such upload backend will need to handle, so I just need to come up with a standard mechanism to trigger the cleanup.
thanks for the heads up. I followed your advice for the observe on my JSSample app and it works like a charm. I look forward to the enhancement.
I think that bug #7 against the sample may be a file-collection bug.