Loosing file name dowloading PRFile

I use Pier in pharo0.1-10268web09.04. When I try to download a File I
added before, original file name is ignored and it is named as 'Pier'
always. The contents is correct.

--
Dennis Schetinin
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Thank you for reporting. I can reproduce this, but not immediately fix this.

I created an issue and will look at this ASAP.

http://code.google.com/p/pier/issues/detail?id=94

Cheers,
Lukas

On Sat, Apr 18, 2009 at 9:32 PM, Dennis Schetinin <[hidden email]> wrote:


--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Serving files seems to be very confusing, as there are so many driving
forces and requirements.

1. The filename. There are two filenames, the one of the structure and
the one of the uploaded file. To me it is not clear which one is
preferable to be used? The one of the structure changes when the file
is renamed, the other one is determined by the original filename of
the upload.

2. The serving. There are two ways to serve files. Serving can either
happen using Seaside (the default) or using Apache (which is much more
efficient). The two approaches have completely different semantics, in
the Seaside case we have full control over the path. The approach with
Apache is limited to how Magritte lays out the files to the
file-system, however that could be fixed using X-Sendfile, but then
requires a non-standard plugin in Apache.

3. The response. In the case Seaside is serving we can set
Content-Disposition in the response. Setting it means that browsers
downloads the file, even if it could be displayed in the browser
window.

Maybe there are even more possible dimensions. Anybody has an idea how
to consistently resolve these problems?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

lukas

this is a pier only  bug?
On Apr 18, 2009, at 10:49 PM, Lukas Renggli wrote:

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>> 1. The filename. There are two filenames, the one of the structure and
>> the one of the uploaded file. To me it is not clear which one is
>> preferable to be used? The one of the structure changes when the file
>> is renamed, the other one is determined by the original filename of
>> the upload.
>
> the extension is sometimes cruical, since windows uses it to offer a program
> that can open it. Can structure names end in .doc?

Yes, that is possible. It is probably more consistent to use the
structure name, because like this one has the possibility to rename.

This is essentially already implemented, see the class side of
MAExternalFileModel or the PRFileSettings widget to change these
properties from the web. The problem with Apache serving is that the
directories have to be obfuscated to not loose security. This is not a
problem for downloads, but for style-sheets for example that sometimes
use relative references to other files. Using X-Sendfile this could be
fixed relatively easy, but this is a non-standard Apache module.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> Maybe offering FileLibrary and its web interface as part of pier, and not
> forcing it to be a structure could be a solution? But in this case user
> rights management that works for structures would be lost.

That's a possibility. Although I've never tried myself, but it should
be possible to add the Seaside application configuration and the
FileLibrary management component into some protected management page.
However this is not really efficient when files get bigger than a few
KB, because these are compiled as Smalltalk methods and thus always in
memory.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> this is a pier only  bug?

As I tried to explain there are several dragging forces here. When one
is fixed, another one breaks. I am trying to find a solution that is
consistent and that works for most setups. Earlier versions did not
show this bug until John McIntosh discovered that enforcing a
file-name in the HTTP header caused the file to always be downloaded
instead of displayed inside the browser window.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 19-Apr-09, at 1:18 AM, Lukas Renggli wrote:

> 3. The response. In the case Seaside is serving we can set
> Content-Disposition in the response. Setting it means that browsers
> downloads the file, even if it could be displayed in the browser
> window.

Ah, I thought I mentioned if you stick "inline" in

WAReponse>>attachmentWithFileName: aString
        self headerAt: 'Content-Disposition' put: 'inline; attachment;  
filename="', aString, '"'

see http://www.ietf.org/rfc/rfc2183.txt

Then Safari is happy to show PDF files in the browser, versus  
downloading

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ahh, interesting. I wasn't aware of that, only that removing the
Content-Disposition altogether has the same effect but also loses
control over the filename. That should solve at least the problems
when the file is served through Squeak/Seaside.

Thanks for the hint.

Lukas




--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

I think you've a copy of WikiServer, use the latest one and give it a  
try.

The other issue was the desire for Magritte to hand back the contents  
of the file to seaside for downloading.
This might be fine on a server, but if you attempt to toss a 64MB file  
on the iPhone you die, well it could
apply to a desktop machine if you move 500MB files.

The problem is

MAExternalFileModel>>urlFor: aRenderingContext
        ^ self baseUrl isNil
                ifTrue: [ super urlFor: aRenderingContext ]
                ifFalse: [ self baseUrl , '/' , (self location reduce: [ :a :b | a ,  
'/' , b ]) , '/' , self filename ]


MAFileModel>>urlFor: aContext
        ^ aContext
                urlForDocument: self contents
                mimeType: self mimetype
                fileName: self filename

See the "self contents"  In WikiServer I changed that to

MAExternalFileModel >>urlFor: aContext

        ^ self baseUrl isNil
                ifTrue: [aContext
                        urlForDocument: self
                        mimeType: self mimetype
                        fileName: self filename]
                ifFalse: [ self baseUrl , '/' , (self location reduce: [ :a :b | a ,  
'/' , b ]) , '/' , self filename ]


Other helper methods I had to add were

MAExternalFileModel>>asMIMEDocumentType: aMimeType
        "for text documents we need to return the proper mime type aware  
document otherwise we get UTF-8 errors
        but for other document types we want a binary type"

        self maintype = 'text'
                ifTrue: [^self readStream asMIMEDocumentType: aMimeType].
        ^self readStreamBinary asMIMEDocumentType: aMimeType

MAExternalFileModel>>readStreamBinary
        "We make a StandardFileStream instance and set to binary, oddly  
someone closes this later and re-opens as
        text if we make a MultiByteFileStream then it starts streaming as  
utf-8 which is a bad thing"

        ^ (self directory readOnlyStandardFileNamed: self filename) binary

FileDirectory>>readOnlyStandardFileNamed: localFileName
        "Open the existing file with the given name in this directory for  
read-only access."

        ^ StandardFileStream readOnlyFileNamed: (self fullNameFor:  
localFileName)


On 19-Apr-09, at 11:03 AM, Lukas Renggli wrote:

>>> Ahh, interesting. I wasn't aware of that, only that removing the
> Content-Disposition altogether has the same effect but also loses
> control over the filename. That should solve at least the problems
> when the file is served through Squeak/Seaside.
>
> Thanks for the hint.
>
> Lukas

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> I think you've a copy of WikiServer, use the latest one and give it a try.

The binary application, yes ;-)

That's a very cool trick. Thanks for sharing.

I integrated the change with Magritte-Seaside-lr.295, however instead
of using the standard WADocumentHandler of Seaside I added my own
handler called MAFileModelHandler. Like this I don't think I need to
worry about ascii/binary modes (AFAIK) and I can avoid unnecessary
copy and cache operations that the default implementation idoes.
Furthermore it does not depend on platform dependent file operations,
something I would like to avoid if possible (for GST, VisualWorks and
GemStone compatibility).

Please give it a try and let me know if this solves at least the
current problems when the file is served through the image.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ok, well I forgot to add the part for the upload side.

Again the issue on the iphone is uploading 50MB files, but for  
desktop, what if someone wants to push 1GB file?

anyway first you have to turn on the KOM stream uploading feature, say  
via

WAKom default streamUploads: true.

now the issue is with
MAFileUploadCompoent>>upload: aFile
        self value: (aFile isNil ifFalse: [
                self description kind new
                        mimetype: aFile contentType;
                        filename: aFile fileName;
                        contents: aFile contents;
                        yourself ])

That sets the content to "aFile contents".

I changed that to

MAFileUploadComponent>>upload: aFile
        self value: (aFile isNil ifFalse: [
                self description kind new
                        mimetype: aFile contentType;
                        filename: aFile fileName;
                        contentsFromWATemporaryFileProxy: aFile;
                        yourself ])


MAFileModel>>contentsFromWATemporaryFilePRoxy: file
        self contents: file contents
and
MAExternalFileModel>>contentsFromWATemporaryFileProxy:  file
        | writeStream readStream |
       
        "Write Stream is a file handle to the Pier storage library,  Read  
Stream will be the WATemporaryFile"
        "Set instance filesave value, and copy file from temporary storage to  
Pier storage"

        writeStream := self writeStream.
        readStream := file stream.
        filesize := readStream size.
       
        [FileDirectory default copyFile: readStream toFile:  writeStream]  
ensure:
                [readStream close.
                writeStream close]

and
WATemporaryFile>>stream
        | stream |
        stream := self temporaryDirectory readOnlyFileNamed: self  
temporaryFileName.
        stream binary.
        ^stream


I note however on the iPhone I do this instead of the copyFile:toFile:

        IPhoneWikiServerUI isiPhone
                ifTrue: [IPhoneWikiServerUI move: readStream to: writeStream.
                                ^self].


and use an operating system call to move the file from one directory  
to the other so the cost is zero, when WATemporaryFileProxy
closes, it runs out the delete the file, but we've move it, guess I  
should add an override...

BTW In Sophie we coded up a os-x api call to either copy or move files  
via OS calls so we could preserve all the file meta-data.
Doing the copyFile: toFile: is just so *primitive* and expensive.


Now if someone want's to test all this that would be great because my  
environment is contaminated with changes and it's a bit hard to  
confirm I"ve detailed all the changes.
We've attempted to mark all our Magrritte/pier/seaside changes as  
overrides or extensions, but it's easy to miss one or two.

Testing in fact is  easy on a desktop machine, for linux based  
machines you would start the VM with a memory configuration of oh say  
40MB depending on your pier image. On the Macintosh make a copy of the  
squeak.app and change the info.plist SqueakMaxHeapSize entry from  
536870912 to 40000000, or you can start the VM on the cmd line (see http://wiki.squeak.org/squeak/105)
  and set -memory 40m   just like you would do on Linux.

This will limit the VM to use 40MB of memory, now attempt to add an  
image file of say 50MB to a pier page.  No doubt you should use the GC/
memory report to confirm what you think you are telling the VM about  
memory upper bound is what it actually is don.g


On 19-Apr-09, at 2:12 PM, Lukas Renggli wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki