[Mac] Upstream WKSetMetadataURL() from WebKitSystemInterface
Created attachment 319246 [details] Patch
Comment on attachment 319246 [details] Patch Clearing flags on attachment: 319246 Committed r221291: <http://trac.webkit.org/changeset/221291>
All reviewed patches have been landed. Closing bug.
<rdar://problem/34128954>
Do we need to do something to avoid exiting the process while this write operation is still in progress?
(In reply to Darin Adler from comment #5) > Do we need to do something to avoid exiting the process while this write > operation is still in progress? That's a good question. Are you concerned about the app terminating before the block executes on the global concurrent queue, or sudden termination while the block is executing? For the former case, failing to add "Where From" metadata seems acceptable. In the latter case, we could use a SuddenTerminationDisabler to ensure the MDItem operation completes.
(In reply to Andy Estes from comment #6) > That's a good question. Are you concerned about the app terminating before > the block executes on the global concurrent queue, or sudden termination > while the block is executing? On Mac and iOS, I’m concerned both about cases where someone explicitly chooses the Quit command and about the case where sudden termination takes effect. There’s also the separate related issue of abnormal terminations like crashes, jetsams, reboots. Given that we are taking about the file system, we should briefly consider all these cases, and what gets left behind. > For the former case, failing to add "Where From" metadata seems acceptable. I am not sure that’s great. If it’s just a normal Quit command I would like to see the quit take slightly longer so the metadata gets attached. I see this metadata as a continuation of the downloading process and I would like it to be treated similarly to the rest of that process. There are some techniques where finishing the job looks to the user like the app is still running; looks like a "hang during the quit process". Others where the job is finished but to the user it looks like the app has already quit; roughly speaking “a daemon finishes the job”. > In the latter case, we could use a SuddenTerminationDisabler to ensure the > MDItem operation completes. Sounds like a good idea. Would be nice to figure out what level of the software is responsible for tying this in with the rest of the I/O to create the file and write out its contents so the whole thing works smoothly and consistently.