Какви са последните четири байта от маркера за запис на неформатиран файл?

По-долу е извадка от шестнадесетичен дъмп на неформатиран Fortran файл (генериран от AERMOD компилиран с gfortran):

00f3ee50: 0000da50 00b746d7 00000001 204c4c41 20202020 462df2dd 403f41fa c5f77f92...     
00f4c886: 6a031d65 f2923f8c 658037cc 01813f8b 740e846e d7f83f8a 93a93e15 da503f89  
00f4c8a8: 0000da50 00b746d8 00000001 204c4c41 20202020 1bce0f33 4040cf25 059a6d45...     
00f5a2de: 04de57c7 6f803fa0 cc5e786d c1983f9e a6fd14ae 05803f9d 970266e8 da503f9c
00f5a300: 0000da50 00b74725 00000001 204c4c41 20202020 9e95fa2a 4087b60e ef189339...     
00f67d36: 7d9a5b20 bbe53fd8 467cf2bf be063fd7 292414d4 0c943fd6 22a6cc90 da503fd5
00f67d58: 0000da50 00b74726 00000001 204c4c41 20202020 92ee2eb6 40868bcc 991a0bf2...     
00f7578e: 128e3196 a8063fe2 2418d1d5 185e3fe1 49a7e799 009a3fe0 01ea4bf1 da503fdf
00f757b0: 0000da50 00b74727 00000001 204c4c41 20202020 00000000 00000000 00000000...     
00f831e6: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 da500000

Всеки запис започва с 0x0000da50 и завършва с 0xda503f## (или 0xda500000, когато е запис пълен с нули). Разбирам, че компилаторът вмъква четири байта в началото и края на всеки запис, за да посочи неговата дължина.

От документацията знам, че всички записи имат постоянна дължина и че първите 16 байта от всеки запис съдържат рутинна информация като броячи и етикети, но не и изчислени данни.

Сега, ако вземете разликата между позициите за два последователни „начални реда на записа“, ще получите 55896 (напр. 0xf4c8a8 - 0xf3ee50 = 55896) и като извадите 8-те байта, които компилаторът е добавил, ще получите 55888 или 0xda50. Така че има само два байта, които дават действителната дължина на записа.

Какво правят последните четири байта от всеки запис?

Актуализация

Открих, че бездомните байтове се появяват само когато определени размери на колони са посочени в xxd. Ето пълни шестнадесетични дъмпове за по-малък файл (генериран с помощта на същата програма Fortran), с две различни спецификации на колони (първо с 16 октета, след това с 25). Може би проблемът е с xxd?

$ xxd -e -c16 test.pst
00000000: 00000250 00b74275 00000001 204c4c41  P...uB......ALL 
00000010: 20202020 1273c268 4042050f 6ec665a7      [email protected]
00000020: 404c165c 2e64c72d 40469557 87eefed5  \[email protected]@....
00000030: 404d86c1 349e2405 40502c03 435bacfe  ..M@.$.4.,P@..[C
00000040: 40501966 fe8ace3c 404e4ef7 7382fb52  f.P@<[email protected]
00000050: 404b73f0 01369ac9 4048029b 19a95098  [email protected]@.P..
00000060: 40442608 39972ac4 403ff81f 87f5457a  .&D@.*.9..?@zE..
00000070: 403760aa 0933541e 402e31cf 96229471  .`[email protected].@q.".
00000080: 40201210 31afaa2e 400ab597 06b2618a  .. @[email protected]..
00000090: 3ff934b7 a5814a70 3ff6c2cf 13454924  .4.?pJ.....?$IE.
000000a0: 3ff6d543 9389bf37 3ff6db74 3630fe04  C..?7...t..?..06
000000b0: 3ff6d48e 0f5e2bc8 3ff6c0b8 fdbc2622  ...?.+^....?"&..
000000c0: 3ff6a063 a26cd9d4 3ff67447 150d1668  c..?..l.Gt.?h...
000000d0: 3ff63d53 37d9abef 3ff5fca5 b6c1bba5  S=.?...7...?....
000000e0: 3ff5b37e be32f197 3ff56334 586c0c65  ~..?..2.4c.?e.lX
000000f0: 3ff50d24 2bcc15c8 3ff4b2a7 15798027  $..?...+...?'.y.
00000100: 3ff4550a dca18880 3ff3f585 039bd6d6  .U.?.......?....
00000110: 3ff3953a 9221d30d 3ff33529 97fa7215  :..?..!.)5.?.r..
00000120: 3ff2d639 1909878a 3ff27931 4e95ad98  9..?....1y.?...N
00000130: 400b42d6 4641e3b8 400a4f52 c5ddb926  [email protected].@&...
00000140: 40096e88 aa92c3ba 40089fd0 93f8d3c8  .n.@.......@....
00000150: 4007e269 749bbc48 40073588 afbbc2f8  [email protected].@....
00000160: 40069860 9005d1f8 40060a2a bde7eb31  `..@....*..@1...
00000170: 40058a27 3a0dc41a 400517a6 434deebc  '..@...:[email protected]
00000180: 4004b202 77353ddd 400458a7 6920fdd8  ...@.=5w.X.@.. i
00000190: 40040b11 dccebcd6 4003c8cb c5b1ee47  ...@.......@G...
000001a0: 40039172 2388cc5f 400364b2 ce0c693f  r..@_..#.d.@?i..
000001b0: 40034245 3c8b166d 400329f9 52837682  EB.@m..<.)[email protected]
000001c0: 40031ba7 377415b1 4003173a 3de1aa1e  [email protected]:..@...=
000001d0: 40031cab dbcb3888 40032c02 b5346967  [email protected]...,.@gi4.
000001e0: 40034558 b7f5a14d 400368d3 466d447d  [email protected].@}DmF
000001f0: 400396aa 6cd87c23 4003cf22 1ad6f796  ...@#|.l"..@....
00000200: 40041292 57a28483 4004615f 63a836e2  [email protected][email protected]
00000210: 4004bc00 b4f68bf3 400522fb b5195f5e  ...@.....".@^_..
00000220: 400596e7 1dd722b0 4006186a 5bf7aba7  ...@."..j..@...[
00000230: 4026b8df b0158858 402bd56c f3245c1f  ..&@X...l.+@.\$.
00000240: 40310f07 e8781d38 4034d28c 97d0997b  [email protected]@{...
00000250: 403a0634 00000250                    4.:@P...

второ:

    $ xxd -e -c25 test.pst
    00000000: 00000250 00b74275 00000001 204c4c41 20202020 1273c268     P.0fuB......ALL     h.s..
    00000019: a7404205 5c6ec665 2d404c16 572e64c7 d5404695 c187eefe     .B86e.n\[email protected]@......
    00000032: 2405404d 2c03349e acfe4050 1966435b ce3c4050 4ef7fe8a     [email protected].,P@..[Cf.P@<....NN
    0000004b: 82fb5240 4b73f073 369ac940 48029b01 a9509840 44260819     @[email protected]@.P...&D@
    00000064: 39972ac4 403ff81f 87f5457a 403760aa 0933541e 402e31cf     .*71..?@zE...`[email protected].@q
    0000007d: 10962294 2e402012 9731afaa 8a400ab5 b706b261 703ff934     ."4a. @[email protected].?pJ
    00000096: c2cfa581 49243ff6 d5431345 bf373ff6 db749389 fe043ff6     ..30.?$IE.C..?7...t..?..0
    000000af: f6d48e36 5e2bc83f f6c0b80f bc26223f f6a063fd 6cd9d43f     6.a2?.+^....?"&..c..?..l.
    000000c8: 3ff67447 150d1668 3ff63d53 37d9abef 3ff5fca5 b6c1bba5     Gt7eh...S=.?...7...?....~
    000000e1: 973ff5b3 34be32f1 653ff563 24586c0c c83ff50d a72bcc15     ..b2.2.4c.?e.lX$..?...+..
    000000fa: 80273ff4 550a1579 88803ff4 f585dca1 d6d63ff3 953a039b     .?f3y..U.?.......?....:..
    00000113: 21d30d3f f3352992 fa72153f f2d63997 09878a3f f2793119     ?.3f.)5.?.r..9..?....1y.?
    0000012c: 4e95ad98 400b42d6 4641e3b8 400a4f52 c5ddb926 40096e88     [email protected].@&....n.@.
    00000145: d0aa92c3 c840089f 6993f8d3 484007e2 88749bbc f8400735     [email protected][email protected].@..
    0000015e: 9860afbb d1f84006 0a2a9005 eb314006 8a27bde7 c41a4005     ..0d.@....*..@1...'..@...
    00000177: 0517a63a 4deebc40 04b20243 353ddd40 0458a777 20fdd840     :[email protected]...@.=5w.X.@.. i
    00000190: 40040b11 dccebcd6 4003c8cb c5b1ee47 40039172 2388cc5f     [email protected]..@_..#.
    000001a9: 3f400364 45ce0c69 6d400342 f93c8b16 82400329 a7528376     d.1bi..EB.@m..<.)[email protected]..
    000001c2: 15b14003 173a3774 aa1e4003 1cab3de1 38884003 2c02dbcb     .@03t7:..@[email protected]...,.
    000001db: 34696740 034558b5 f5a14d40 0368d3b7 6d447d40 0396aa46     @[email protected].@}DmF...@
    000001f4: 6cd87c23 4003cf22 1ad6f796 40041292 57a28483 4004615f     #|e2"..@[email protected]_a.@.
    0000020d: 0063a836 f34004bc fbb4f68b 5e400522 e7b5195f b0400596     6.22..@.....".@^_.....@."
    00000226: 186a1dd7 aba74006 b8df5bf7 88584026 d56cb015 5c1f402b     ..24.@...[..&@X...l.+@.\$
    0000023f: 310f07f3 781d3840 34d28ce8 d0997b40 3a063497 00025040     [email protected]@{...4.:@P...

След 16-байтов преамбюл (завършващ с 202020), изходът трябва да бъде поредица от 72 числа. Тъй като те заемат 576 байта, предполагам, че те са реални числа с двойна точност във Fortran:

36.03952 56.17470 45.16672 59.05278 64.68770 64.39687 60.61694 54.90578 48.02036 40.29712 31.96923 23.37760 15.09728 8.03528 3.33867 1.57537 1.42256 1.42707 1.42858 1.42689 1.42205 1.41416 1.40339 1.38997 1.37418 1.35632 1.33672 1.31571 1.29362 1.27076 1.24744 1.22393 1.20048 1.17730 1.15459 3.40764 3.28873 3.17897 3.07803 2.98555 2.90114 2.82440 2.75496 2.69246 2.63655 2.58692 2.54329 2.50540 2.47305 2.44602 2.42417 2.40736 2.39549 2.38850 2.38634 2.38900 2.39649 2.40886 2.42619 2.44857 2.47614 2.50907 2.54755 2.59180 2.64208 2.69868 2.76192 11.36108 13.91684 17.05872 20.82246 26.02424

gfortran fortran binaryfiles xxd
person Community    schedule 30.01.2017    source източник
comment
Това за файл с последователен достъп ли е? Имайте предвид, че това, което се записва на диска, може да варира в зависимост от отворените спецификатори, опциите за компилиране и променливите на средата. По подразбиране дължините на началния и крайния запис са четири байта.   -  person IanH    schedule 30.01.2017
comment
@IanH Операторът OPEN в изходния код няма посочен флаг FORM. Мисля, че това означава, че по подразбиране е последователен достъп.   -  person    schedule 30.01.2017
comment
ACCESS е спецификаторът, който трябва да търсите. Да - по подразбиране, ако не е указано друго, е ПОСЛЕДОВАТЕЛЕН.   -  person IanH    schedule 30.01.2017
comment
Но ако е последователен, тогава формата трябва да бъде указана на неформатиран   -  person Vladimir F    schedule 30.01.2017
comment
Първите и последните четири байта от всеки последователен неформатиран запис, създаден от gfortran, ТРЯБВА да бъдат дължината на записа. (Изключение е, ако записът е по-дълъг от 1 GB, в който случай има направени някои други неща.) Бих искал да видя целия файл за повече анализ, но ако това, което показвате, е точно, ще се чудя дали има грешка в gfortran. Обърнете внимание, че използването на дължини на записи като това е изцяло зависимо от изпълнението и не е непременно преносимо (въпреки че повечето съвременни компилатори използват подобен метод.)   -  person Steve Lionel    schedule 31.01.2017
comment
@SteveLionel благодаря за коментара. Файлът, който гледах, беше около 500 Mb (въпреки че ще се радвам да ви го изпратя, ако желаете да го погледнете). Опитах се да генерирам много по-кратък (около 0,3 Mb), чиито записи бяха само по 32 байта. Интересното е, че получавам 00000020 00b74275 00000001 204c4c41 20202020 53aad716 3e95eac5 56a96a69 3f1370da 00000020 като един от записите (обърнете внимание, че първите и последните четири байта имат само дължината на записа и нямат мистериозни байтове). Чудя се дали проблемът е свързан с големия размер на записа.   -  person    schedule 31.01.2017
comment
Тествайте с файл само с един запис и покажете кода (тестовият пример трябва да е много кратък) и покажете началото и края на шестнадесетичния дъмп.   -  person agentp    schedule 31.01.2017
comment
@agentp това е добра идея. Започнах да играя с едноредов двоичен файл и открих, че бездомните байтове се появяват или изчезват в зависимост от броя на колоните, посочени в xxd. Ще актуализирам въпроса въз основа на това.   -  person    schedule 01.02.2017
comment
изглежда, че указването на байтове на ред, които не са кратни на четири, обърква нещата. Има и други проблеми, например първият байт (a7) във втория ред не се появява в първата последователност   -  person agentp    schedule 01.02.2017
comment
@agentp добър улов. Сега искам да видя дали всяка версия е действително правилният изход, ако бъде анализирана. Резултатът трябва да бъде поредица от 72 числа. Ще ги добавя към текста на въпроса.   -  person    schedule 01.02.2017
comment
@agentp a7 определено не трябва да е там, тъй като мисля, че 1273c268 4042050f е предназначен да представлява 36.03952 (трябва да го прочетете като 0x4042050F1273C268).   -  person    schedule 01.02.2017

Отговори (1)


arrow_upward
1
arrow_downward

Анализирайки файла с функцията perl unpack, мога да отчитам правилно всички байтове. Изглежда, че това е малък проблем с xxd, когато се използват определени размери на колони.

person Community    schedule 09.10.2017