Usage of String and FileLocator to reference files in ZipArchive (and probably other places)

Hi, I've stumbled upon a 7.0 incompatibility with regards to how file names
are treated.
In 6.1, I can use Strings and FileLocators interchangeably to create and
read Zip archives. That's because StandardFileStream does the magic behind
the screnes.
In 7.0, StandardFileStream has been deprecated, and "File
openForReadFileNamed:" is used instead. That method does not handle
FileLocators, so code that uses FileLocators to open Zip archives ceased to
work.

What's the preferred solution? It strikes me as illogical that objects which
were made to reference files can't be used to reference files in these
contexts. However, there may be a conscious design decision behind this
change that's just not obvious to me.

Cheers,
Hans-Martin



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

> On 17 Nov 2018, at 16:04, Hans-Martin <[hidden email]> wrote:
>
> Hi, I've stumbled upon a 7.0 incompatibility with regards to how file names
> are treated.
> In 6.1, I can use Strings and FileLocators interchangeably to create and
> read Zip archives. That's because StandardFileStream does the magic behind
> the screnes.

Could you give a code example ? What API/methods are you talking about ?

What worked before and does not work anymore ?

> In 7.0, StandardFileStream has been deprecated, and "File
> openForReadFileNamed:" is used instead. That method does not handle
> FileLocators, so code that uses FileLocators to open Zip archives ceased to
> work.

*NO* you should not use File directly.

Just use FileReference instances (however you create them) and work from there. If you got a string path, use #asFileReference.

  FileLocator desktop / 'foo.txt readStreamDo: [ :in | in upToEnd ]

MyObject>>#readFromFile: file
  ^ file asFileReference readStreamDo: [ :in | self readFromStream: in ]

Ok here's an example:

ZipArchive isZipArchive: FileLocator temp / 'nonexist.zip'

In 6.1, this brings up the nonexistant file dialog if the file does not
exist, otherwise it returns true or false depending on whether the file is a
zip archive.
In 7.0, you get an error "Instance of FileLocator did not understand
#utf8Encoded" independent of whether the file exists, is a zip archive or
not :-)

Cheers,
Hans-Martin



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

 ok, I had a quick look.

the whole ZIP archive code has quite close ties with File (and vice versa: a lot of methods on File are only used by that code), while I don't think this is strictly necessary.

I know that this has historical reasons.

some more work needs to be done here.

I found a related problem which indicates that the depreciation of
StandardFileStream in favor of File is incomplete and probably premature:

When a ZipArchive is written, in 7.0 it uses
        (File named: aFileName)
                writeStreamDo: [...]
In 6.1, it uses
        StandardFileStream
                forceNewFileNamed: aFileName
                do: [...]
which is a small but significant difference leading to corrupted zip
archives when overwriting existing files. File does not have equivalent
protocol to #forceNewFileNamed... so it is pretty likely that there are more
bugs creeping there. Upon a cursory inspection I see that for example
FLFileStreamStrategy will suffer from the same problem when writing to
existing files.

Is there any documentation on the reasoning of depreciating
StandardFileStream and who is working on this? I'm really new to pharo
development... Submitting "patches" without knowing the original design
rationale seems not very productive.

Cheers,
Hans-Martin



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html