[6116]

So I've been trying to write a nested list to a file to be accessed later, but there's something odd going on. I've tried to get it down to its simplest case:

set configData to {{"x"}, {"y"}} -- the nested list

open for access file ((path to desktop folder as string) & "config") with write permission
set configFile to result
set eof of configFile to 0
write configData to configFile as list
close access configFile
display dialog first item of first item of configData -- the nested list seems to work fine here
display dialog first item of second item of configData
open for access file ((path to desktop folder as string) & "config")
set configFile to result
set configData to (read configFile as list)
close access configFile
display dialog first item of first item of configData -- the list works fine here too
display dialog first item of second item of configData -- and then it gets weird

If you run that script, it'll be able to use the data fine before it gets written to the file. But reading it back corrupts it. Anyone know what might be going on.

Thanks

[Paul Crawford]

Hi again 6116,

This one's a strange beast indeed... I just ran your test script today, and can confirm that the 'read' command is retrieving the list incorrectly from the disk file. The problem actually seems to be caused by a bug in the 'write' command, as I think that each list-member's overall data -- including the four-byte descriptor(s), the four-byte length-field(s), plus the data itself -- is supposed to be written to occupy an even number of bytes on disk (padded with trailing nulls, if necessary). [See the related threads in the MACSCRPT Mailing List Archives (e.g. Writing lists to files (was: Creating file w/o opening)). The situation is clearer if you open the disk file in any hex editor to see the exact layout of the written data; if you don't already have a hex editor, you could download Lane Roathe's freeware HexEdit utility.]

From the 'read' command's perspective, each list member's overall data is expected to begin and end on an even, halfword boundary. Otherwise, starting bytes would be dropped from subsequent descriptor(s) of the second, third, etc., members. Take for instance the initial 'list' descriptor of the second member (the nested-list {"y"}); due to the bug, what should be read as 'list' («class list») becomes instead an uninterpretable 'ist<null>' («class ist<null>») because the initial 'l' is skipped.

In other words, lists that would be read correctly for all members include the following:-
{{"xx"}, {"y"}}
{{"xx"}, {"yy"}}
{{"xx"}, {"yy"}, {"zz"}}
{{"xx"}, {"yyy"}}

On the other hand, lists that would be read incorrectly for at least one member include the following (in addition to your own example):-
{{"x"}, {"yy"}} -- Chokes on descriptor of second member
{{"xxx"}, {"yy"}} -- Chokes on descriptor of second member
{{"xx"}, {"y"}, {"zz"}} -- Chokes on descriptor of third member
{{"xx"}, {"yyy"}, {"zz"}} -- Chokes on descriptor of third member

Interestingly enough, the following list (which contains direct strings rather than nested-lists of strings) also works well, because the second member's text-data is correctly written padded with a trailing null, and occupies four bytes as "yyy<null>":-
{"xx", "yyy", "zz"} -- Non-nested text strings

Unfortunately, this glitch involving written nested-list data will be something you'll always have to remember as you write a list to disk. Alternatively, you could try manually converting a list into delimited text format, and then writing the resulting string to disk "as text" instead. You could then later retrieve the list members by reading the data "as text using delimiters {...}", and reconstruct the list.

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 07-11-2000).]

[6116]

Thanks for the help, Paul. I did some digging on Apple's site, and near the bottom of the page of a list of features of OS8.5,(http://developer.apple.com/technotes/tn/tn1142/singlepart.html)

It says "The Read/Write Commands can now read lists of lists correctly." I guess I should start using OS8.5 again.