"TimM" <
[hidden email]> wrote in message
news:
[hidden email]...
>I just happened to notice that the method File>>temporaryFilename
> doesn't produce a unique temporary filename but actualy creates a file
> that backs the name (i.e. it basically works the same as
> File>>temporary).
>
> Looking at the MSDN I can see why this is the case - creating the file
> insures that you get a unique filename (and some other process doesn't
> create one) - although its a slimy OS hack if you ask me (you would
> think an OS would manage temporary files for you geezzz).
The basic way that it works doesn't seem unreasonable to me. How else are
you going to guarantee uniqueness but to create some kind of artefact, and
why shouldn't that be a file?
Would be useful if it more actively managed the temp file space and deleted
old temp files though.
>
> While you can change the undelying smalltalk method call there is an
> INT parameter that if non 0 will generate a filename but its not
> guaranteed to be unique.
Well I don't know about you, but that doesn't seem very useful to me.
>
> I wonder if the best thing is to document this side effect in the
> method comment (it caught me out - I have hundreds of temp files from
> constantly runnig some tests ;-)
Yes. The comment needs to be fixed anyway, since it wrongly mentions the
current directory, whereas the temp file is in the temp directory.
> By the way - on the topic of files, why is there no method to open a
> readOnly file - e.g. File class>>readonly:
>
> I know there is #open:mode: (and then you search around and find the
> symbols #read, #write etc) but it seems odd that we expose a symbolic
> mode to open a read only file?
>
Because normally one manages files through FileStream (and in fact
FileStream has documented protocols in the ANSI standard which are
implemented in Dolphin, whereas it makes no reference to a File class).
FileStream class has a #read: method to open a file in read-only mode.
Regards
Blair
Locked
