David Smith

@Catfish_Man Similar issue just creating a URL. And in bulk it’s slow even with an SSD.

@mjtsai yeah, syscalls aren’t cheap :/

@Catfish_Man Yeah. What happens if the resource changes type after I create the URL? In general, I can’t prevent that from happening…

(The former has to stat() the file to see if it should append a "/" or not, and this task is running on a network filesystem)

@Catfish_Man I thought stat() was unsafe?

@queersorceress hm. Howso? I hope it isn't, we use it all over the place!

@Catfish_Man oh wait never mind, i was misremembering the type of bug that it was.

@Catfish_Man I was thinking of a case where some software was stating the file by name rather than by node.

@queersorceress ah, that can be an issue, but that sort of time-of-check-time-of-use race is already inherent to the task in this case

@Catfish_Man yup! I was misremebering the purpose of the replacement stat function there.

@Catfish_Man :-( Yeah, I think this is a case where "past Foundation engineer designed the wrong API". It /keeps coming up/.

@UINT_MIN it’s worse than that… the flaw is in UNIX paths. Unless you can make the trailing / optional, it’s very hard to avoid.

@Catfish_Man YES THE TRAILING / SHOULD BE OPTIONAL NSURL doesn't always represent an actual resource, so it shouldn't eagerly canonicalize.

@UINT_MIN hm. This seems fraught with peril, but we could talk to Jim about exploring it.

@Catfish_Man Ah, yeah, I'd expect /changing/ the behavior now could easily be far worse than continuing to accept it.

@UINT_MIN on the plus side though, we have *way* cheaper/dependency-free linked-on-or-after checks now. Opens up new possibilities.