Posted: 12 Feb 2018 04:30 AM PST
In Book 14 of Ovid’s Metamorphoses, Aeneas is at last making his way up the coast of Italy towards his destiny, leading to the foundation of the city and empire of Rome.
Having cleared the dangers of Scylla and Charybdis, and seen the Cercopes who had been transformed into apes, Aeneas and his crew pass the city of Naples, and land at Cumae to visit the Sibyl there in her cave. Aeneas needs to do this in order to go to the underworld to speak to the ghost of his father Anchises.
The Sibyl reassures Aeneas that he will achieve his goals, and to that end she takes him to Proserpine’s sacred glade. Finding a golden bough there, she tells Aeneas to break that from the tree. Bearing that bough, the two of them travel to the underworld, make contact with the ghost of Anchises, and return safely.
During their walk back, Aeneas thanks the Sibyl for her help and guidance, and offers to build a temple to her, assuming that she is a goddess. The Sibyl points out that she is no goddess, and explains how she had once been offered immortality if she were to let the god Apollo take her virginity:
Aeneas and the Sibyl then reach Cumae, and he moves on to his next adventure.
The two interlinked stories of Apollo and the Sibyl of Cumae, and Aeneas and the Sibyl, have both attracted the attention of several Masters. Indeed one, JMW Turner, cut his mythological teeth on them, and during the rest of his career painted at least three more works showing the Sibyl.
I start with one of Claude Lorrain’s most wonderful coastal landscapes, his Coast View with Apollo and the Cumaean Sibyl from about 1645-49. Although their figures are small, Apollo on the left is holding his lyre in his left arm, trying to persuade the seated Sibyl, to the right, to let him take her virginity.
Around them are the ruins of classical buildings and a stand of tall trees, as the land drops away to an idealised view of the coast of Italy. I suspect that the island on the horizon is based on Capri. In the small bay immediately below them are some ships, which may be a reference to Aeneas’ future visit to the Sibyl, although that would have been centuries later according to the Sibyl’s account of her age.
JMW Turner didn’t tackle this first part of the story until 1823, when he painted The Bay of Baiae, with Apollo and the Sibyl. His view appears to have been loosely based on Claude’s, with common elements, but has been recast at Baiae, in the Bay of Naples. Apollo is again on the left, with his lyre, but the dark-haired Sibyl has adopted an odd kneeling position. She is holding some sand in the palm of her right hand, asking Apollo to grant her as many years of life as there are grains.
Opposite the couple, on the other side of the path, under the trees, is a white rabbit.
When Claude was painting his coastal view, François Perrier was painting a more conventional figurative account of Aeneas and the Cumaean Sibyl (c 1646). Aeneas, stood to the left of the incense burner, appears to be offering to burn incense in honour of the Sibyl, who stands at the right in front of her cave, and is just about to tell him her life-story.
Behind Aeneas is a queue of people, including a king, bearing gifts and waiting to consult with the Sibyl. At the top left corner is a temple, and in the clouds above it the god Apollo, I believe.
JMW Turner’s first version of this scene is thought to have been his first mythological painting, back in his early career, in about 1798. This second version, Lake Avernus: Aeneas and the Cumaean Sybil, dates from 1814 or 1815, and is both an improvement on the original and in better condition.
True to the spirit of Claude’s landscape, this too is a mythological landscape showing the beautiful setting of Lake Avernus, near Pozzuoli, to the west of the city of Naples. In the distance is Baiae and the cliffs of Cape Miseno.
The Sibyl, who does not show her years, holds aloft a golden sprig rather than a bough, and Aeneas stands with his back to the viewer, as if he too is enjoying the view.
Turner’s last account is The Golden Bough, which he exhibited in 1834. It shows well how much his style had changed, although it retains compositional features from his earlier paintings.
The Sibyl stands on the left, radiant in white light, and holding aloft a more substantial golden branch than Turner showed previously. Her right hand holds a golden sickle used to cut that branch. Down towards Lake Avernus are the Fates, dancing around another white glow. A couple of female companions of the Sibyl rest under the tree, but Aeneas is nowhere to be seen (he might be in the middle of the Fates, perhaps). In the right foreground is a snake, a symbol of the underworld.
Of the straight paintings of the Sibyl, hardly any show her as the seven hundred year-old woman of Ovid’s (and Virgil’s) accounts.
The painting which comes closest is probably Elihu Vedder’s The Cumean Sibyl of 1876. However, rather than show the Sibyl in the context of Aeneas’ story, he prefers to depict her in her other main role, going to sell the Sibylline books of prophecies to the last king of Rome. She strides out clutching these scrolls under her arm.
There are also many fine paintings of Aeneas and the Sibyl visiting the underworld, which I will examine on another occasion.
The English translation of Ovid above is taken from Ovid. Metamorphoses. Tr. Brookes More. Boston. Cornhill Publishing Co. 1922, at Perseus. I am very grateful to Perseus at Tufts for this.
Posted: 11 Feb 2018 11:30 PM PST
It’s a simple question: we know that Mac files can have data and extended attributes (xattrs), and we know that the Finder, the
I thought that I had found the answer when I happened across a URLResourceKey named totalFileSizeKey. As with most other things, macOS provides multiple methods for finding out the size of a file. You can use a FileManager call, for example, which only gives the size of the data fork of a file without the xattrs.
The macOS programming class which provides most information about files is URL. It has quite an elaborate interface which involves telling a file URL object which ‘keys’ you want it to reveal, then accessing those that you want. In this case, the URLResourceKey in question is totalFileSize, which Apple’s developer documentation describes as:
Note that this doesn’t refer specifically to extended attributes, but to “file metadata”. Off the top of my head, I cannot think of any other metadata which wouldn’t be included in the data fork size, so I assumed that this actually means the total size of all extended attributes.
I don’t know of any app or tool which displays the value for that URLResourceKey, so I had to write my own – Precize, which you can download from here: precize10b1
Precize displays three measures of file size, for the data fork alone, the xattrs alone, and the total of both, using two different methods. The first row URL Keys gives the values derived from Apple’s URLResourceKeys, and the second from FileManager and examining each of the xattrs. The ‘correct’ total is that in the lower right corner, in bytes.
Armed with that tool, I discovered that no single figure obtained from macOS gives the total size of a file’s xattrs, nor the total size of those together with its data fork. In other words, you cannot obtain from macOS the full size of any of its files, unless they don’t contain any xattrs, in which case their total size is the same as that of their data fork.
What does totalFileSize return? It is a number between the data fork size and the true total file size, but is very seldom the same as the latter. As far as I can tell, the only xattr which it includes as “file metadata” is the classic Resource fork, a xattr of type com.apple.ResourceFork. This means that it is functioning as in Classic Mac OS, in only considering one data and one resource fork per file.
URL’s totalFileSize does not take into account the following widely used xattrs:
Thus there seems very little point in ever using totalFileSize.
The evidence from Precize is that the only accurate way to measure the full size of a Mac file is to total the sizes of each of its xattrs, and add those to the size of its data fork. That doesn’t appear to be a function performed by macOS, or at least it is not exposed anywhere to developers or users. So, as far as I can tell, macOS itself doesn’t have any direct access to the total size of any of its files – which seems a startling omission.
The situation on macOS High Sierra, with its shiny new file system APFS, is exactly the same as in Sierra running on HFS+.
Where it does become more complex, if not downright weird, is with iCloud Drive, and its xattr filtering. To test this, I Zipped some test files with abundant xattrs and moved them onto my iCloud Drive. I then unZipped them on iCloud Drive using one Mac, and checked their sizes using Precize from that Mac and a different one, simultaneously.
The effect of iCloud Drive’s xattr filter is to show that almost all files with xattrs, viewed from two Macs at the same time, have different sizes, as shown below. Although this follows logically from the effect of the filter, it seems to defy good sense and confirms how iCloud Drive doesn’t respect your file content.
But most xattrs are small, and this doesn’t really have any significance, does it?
Like all current features of macOS which are not deprecated, xattrs are there to be used; Apple and third-party developers do store important information in xattrs, and that does build into significant quantities. I have 1.7 million files in the Home folder on my iMac, of which over 750,000 have xattrs. If their average size is 1 KB, then those xattrs alone occupy nearly 0.8 GB, which as far as macOS is concerned is essentially unaccounted for.
Xattrs are handled correctly in many functions of macOS, such as moving, copying, and duplicating files. It seems more than remiss that macOS doesn’t seem to know their total size for each file, without laboriously enumerating each of the xattrs and totting up their sizes. To not provide that information to users also seems careless.
|You are subscribed to email updates from The Eclectic Light Company. |
To stop receiving these emails, you may unsubscribe now.
|Email delivery powered by Google|
|Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States|