[squeak-dev] #newFileNamed: has curious and ancient flaw

monty monty2 at programmer.net
Sun Dec 3 05:26:24 UTC 2017


> Sent: Saturday, November 25, 2017 at 9:46 PM
> From: "tim Rowledge" <tim at rowledge.org>
> To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> Subject: [squeak-dev] #newFileNamed: has curious and ancient flaw
>
> … and another thing - take a look at StandardFileStream class>>#newFileNamed:. Note that it carefully checks to see if a file of the requested name already exists? Sounds very sensible

Does it? Checking to see if a file exists first and then opening it for writing/creation after is an obvious race condition, which could result in data loss. The open and existence check need to be done together atomically, failing when the file already exists. This is the type of little thing where if we don't get it right, we look amateur.

We have sqFileOpenNew() in newer VMs (it's unused in the image though), but it uses a boolean flag parameter to distinguish between failure caused by the file existing and all other causes, and I'd rather have a set of FilePlugin error codes, which could be mapped to file exceptions in the image, to provide better info for why a file operation failed, and also to fix certain file methods I've seen that just assume a particular reason for a failure.

Eliot was in the middle of a house move, so I'll remind him about this: http://forum.world.st/Custom-module-primitive-error-codes-td4966882.html

> , even though the message is not the best name I could imagein for the job.
> Unfortunately, if you take a look at how it is implemented you’ll notice FileDirectory>fileExists: which again sounds very reasonable.   I’d argue that it is not appropriate for an instance method on a particular directory to be worrying about other directories (this is one place where #asFileName is not ridiculous) but never mind - the important part here is that it carefully makes sure to check we only check files and not directories. Which is of course sensible because we are checking if a *file* exists. 
> 
> But going back up the stack we notice that this means our test for a pre-existing use of the requested file name will not detect a *directory* of that name. How many filing systems can support a directory containing a file and another directory of the same name? Obviously this can’t in practice be a huge issue since I’ve never seen any mention of it causing a problem but it is a stupid hole in the semantics. Just another one to add to the list...
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Oyster (n.), a person who sprinkles his conversation with Yiddishisms.
> 
> 
> 
>


More information about the Squeak-dev mailing list