GH-38971: [C++] Fix spelling (filesystem)

[jsoref]

Rationale for this change

What changes are included in this PR?

Spelling fixes to cpp/src/arrow/filesystem/

Are these changes tested?

Are there any user-facing changes?

• Closes: [C++][FileSystem] Spelling errors identified by check-spelling  #38971

[github-actions]

⚠️ GitHub issue #38971 has been automatically assigned in GitHub to PR creator.

[pitrou]

Is "can not" really incorrect?

[jsoref]

I subscribe to Grammarly's view:

https://www.grammarly.com/blog/cannot-or-can-not/

Don’t use can not when you mean cannot. The only time you’re likely to see can not written as separate words is when the word “can” happens to precede some other phrase that happens to start with “not”:

• Can’t is a contraction of cannot, and it’s best suited for informal writing.
• In formal writing and where contractions are frowned upon, use cannot.
• It is possible to write can not, but you generally find it only as part of some other construction, such as “not only . . . but also.”

---

MW's write-up is slightly more tolerant, but not particularly different: https://www.merriam-webster.com/grammar/cannot-vs-can-not-is-there-a-difference

Both cannot and can not are perfectly fine, but cannot is far more common and is therefore recommended, especially in any kind of formal writing. Can't has the same meaning, but as with contractions in general, it is somewhat informal. In some cases, the not following can is in fact part of another phrase, such as “not only"; in such instances can not is the appropriate choice.

In general, I'd encourage only using can not when it's actually meant in a case where cannot is wrong to call out "this isn't cannot, it's can not only (or similar).

Cannot has been in use since the 15th century. We don’t know why English speakers thought it’d be a good idea to zip the two words together to form one; they didn’t seem to see much use in doing the same to do not or is not or have not.

[jsoref]

The problem with the current text is that it's hard to know if it's saying Can <choose> not-<to>-initialise an ObjectInputFile or if it's saying Cannot initialise an ObjectInputFile -- that ambiguity is dangerous and ambiguity should be avoided (especially when it's incredibly cheap, as here).

[pitrou]

As a non-native English reader, I would never interpreter "can not X" as "can choose not to X". For that, I would say and expect "may X".

[pitrou]

In the end, the reason there might be resistance to such trivial changes is that they tend to make commit history less easy to explore for meaningful changes.

[jsoref]

I've been making contributions like these for years (probably over a decade really...), I don't mind pushback and I understand the concerns. I spent a dozen years working on a large project where I did a nontrivial amount of cvs-archeology (even once the project was no longer using CVS...).

These days, https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ means it's easier for devs to skip past commits like this (and at this point, arrow already has quite a few of my commits because this project requested that pieces be split to aid in reviewing/merging). -- Once these PRs are all merged, I'd be happy to create a PR to add .git-blame-ignore-revs with all of the related commits if people are interested.

[pitrou]

Ok. Well I don't have any strong feelings about this, so if nobody else opposes it, I think it's good to go.

[pitrou]

Adding a .git-blame-ignore-revs post-hoc might be useful indeed.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 1b5e26d.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 1 possible false positive for unstable benchmarks that are known to sometimes produce them.