Metadata don't distinguish between Fortran- and C-order arrays?
I am confused how the metadata seems to not indicate if an array is stored in column- or row-major order.
Based on #538, and triggered by [this HackerNews comment](https://news.ycombinator.com/item?id=33092662), I came up with this example:
```python
import numpy as np
import asdf

farray = np.array([[11,12,13], [21,22,23]], order='F')
carray = np.array([[11,12,13], [21,22,23]], order='C')
file = asdf.AsdfFile({"farray": farray, "carray": carray})
file.write_to("strides.asdf")

file2 = asdf.open("strides.asdf")

farray2 = file2.tree["farray"]
print("Original farray:\n", farray[:,:])
print("Recovered farray:\n", farray2[:,:])
carray2 = file2.tree["carray"]
print("Original carray:\n", carray[:,:])
print("Recovered carray:\n", carray2[:,:])
```
which, when running with current asdf from conda, successfully recovers the arrays correctly:
```
Original farray:
 [[11 12 13]
 [21 22 23]]
Recovered farray:
 [[11 12 13]
 [21 22 23]]
Original carray:
 [[11 12 13]
 [21 22 23]]
Recovered carray:
 [[11 12 13]
 [21 22 23]]
```

However, the header of the created file shows no indication that those two arrays have different order:
```yaml
#ASDF 1.0.0
#ASDF_STANDARD 1.5.0
%YAML 1.1
%TAG ! tag:stsci.edu:asdf/
--- !core/asdf-1.1.0
asdf_library: !core/software-1.0.0 {author: The ASDF Developers, homepage: 'http://github.com/asdf-format/asdf',
  name: asdf, version: 2.13.0}
history:
  extensions:
  - !core/extension_metadata-1.0.0
    extension_class: asdf.extension.BuiltinExtension
    software: !core/software-1.0.0 {name: asdf, version: 2.13.0}
carray: !core/ndarray-1.0.0
  source: 0
  datatype: int32
  byteorder: little
  shape: [2, 3]
farray: !core/ndarray-1.0.0
  source: 2
  datatype: int32
  byteorder: little
  shape: [2, 3]
...
```
How can this successfully round-trip arrays if the row/column-major information is not contained in the metadata? Is this using some numpy-specific thing (cf #827) when saving the contents to disk?

From [the standard](https://asdf.readthedocs.io/en/stable/asdf/arrays.html?highlight=strides#sharing-of-data), assuming it's _stored_ in C order, I would have expected that the F-array would have gotten a `strides` entry. 
If it's actually stored in F-order, how is a loading program able to determine that?
If the data is not stored in the order in which it was presented to asdf, does that have performance implications?

I didn't know if this is a standards-related issue or one of the Python implementation.
diff --git a/CHANGES.rst b/CHANGES.rst
index 1e3da514..ee1079c9 100644
--- a/CHANGES.rst
+++ b/CHANGES.rst
@@ -5,6 +5,7 @@
 - Add search support to `~asdf.AsdfFile.schema_info`. [#1187]
 - Add `asdf.search.AsdfSearchResult` support for `~asdf.AsdfFile.schema_info` and
   `~asdf.search.AsdfSearchResult.schema_info` method. [#1197]
+- Use forc ndarray flag to correctly test for fortran array contiguity [#1206]
 
 2.13.0 (2022-08-19)
 -------------------
diff --git a/asdf/tags/core/ndarray.py b/asdf/tags/core/ndarray.py
index ea06071e..d1b972ec 100644
--- a/asdf/tags/core/ndarray.py
+++ b/asdf/tags/core/ndarray.py
@@ -424,7 +424,7 @@ class NDArrayType(AsdfType):
         # is contiguous.  If not, we need to make a copy to avoid
         # writing a nonsense view.
         base = util.get_array_base(data)
-        if not base.flags.contiguous:
+        if not base.flags.forc:
             data = np.ascontiguousarray(data)
             base = util.get_array_base(data)
 
diff --git a/asdf/tags/core/tests/test_ndarray.py b/asdf/tags/core/tests/test_ndarray.py
index 6d3bc1e1..e707f023 100644
--- a/asdf/tags/core/tests/test_ndarray.py
+++ b/asdf/tags/core/tests/test_ndarray.py
@@ -796,9 +796,18 @@ def test_non_contiguous_base_array(tmpdir):
 
 
 def test_fortran_order(tmpdir):
-    array = np.array([[11, 12, 13], [21, 22, 23]], order="F")
+    array = np.array([[11, 12, 13], [21, 22, 23]], order="F", dtype=np.int64)
     tree = dict(data=array)
-    helpers.assert_roundtrip_tree(tree, tmpdir)
+
+    def check_f_order(t):
+        assert t["data"].flags.fortran
+        assert np.all(np.isclose(array, t["data"]))
+
+    def check_raw_yaml(content):
+        tree = yaml.safe_load(re.sub(rb"!core/\S+", b"", content))
+        assert tree["data"]["strides"] == [8, 16]
+
+    helpers.assert_roundtrip_tree(tree, tmpdir, asdf_check_func=check_f_order, raw_yaml_check_func=check_raw_yaml)
 
 
 def test_readonly(tmpdir):
diff --git a/asdf/tests/test_array_blocks.py b/asdf/tests/test_array_blocks.py
index d0bfaea5..63a4096c 100644
--- a/asdf/tests/test_array_blocks.py
+++ b/asdf/tests/test_array_blocks.py
@@ -794,3 +794,17 @@ def test_add_block_before_fully_loaded(tmp_path):
         assert_array_equal(af["arr0"], arr0)
         assert_array_equal(af["arr1"], arr1)
         assert_array_equal(af["arr2"], arr2)
+
+
+def test_block_allocation_on_validate():
+    """
+    Verify that no additional block is allocated when a tree
+    containing a fortran ordered array is validated
+
+    See https://github.com/asdf-format/asdf/issues/1205
+    """
+    array = np.array([[11, 12, 13], [21, 22, 23]], order="F")
+    af = asdf.AsdfFile({"array": array})
+    assert len(list(af.blocks.blocks)) == 1
+    af.validate()
+    assert len(list(af.blocks.blocks)) == 1
['asdf/tags/core/tests/test_ndarray.py', 'asdf/tags/core/ndarray.py', 'asdf/tests/test_array_blocks.py', 'CHANGES.rst']