• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WOFileUpload ANOTHER bug
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WOFileUpload ANOTHER bug


  • Subject: Re: WOFileUpload ANOTHER bug
  • From: Jonathan Rochkind <email@hidden>
  • Date: Thu, 06 Mar 2003 10:05:53 -0600

At 12:05 AM 3/6/2003 -0800, Aleksey Novicov wrote:
Jonathan,

I'm seeing the exact same problem on Solaris. Everything works fine under OS X - the files get uploaded to where I want them uploaded. But deployed under Solaris, the files seem to always get put in /var/tmp, even with the process running as root. My next strategy is to let WO do what it wants to do, and then copy the files using Java APIs to where I WANT them:-) If anyone comes up a solution to this problem I would love to hear it.

What I've decided to do is ignore the streamToFile binding altogether. It's just too buggy. Instead, I use the outputStream binding, and create my own FileOutputStream to bind to it. This requires just a bit more work, as there are things the streamToFile binding theoretically does for you (dealing with an existing file in the way, primarily) but seems to be working fine.


By the way, I was also stung with the same problem you had with actions for submit buttons associated with a WOFileUpload not being called when submitted!

Yes, the new 5.2 WOFileUpload is incredibly buggy. The bugs include:
1) The 'overwrite' binding seems to be ignored on Windows. Existing files will never be overwritten with fileToStream.
2) If a WOFileUpload is the FIRST element of a form in a multiple-submit form, the submit button actions won't be called. You need to put another dynamic element (a hidden input if neccesary) first in the form. Or don't use a multiple submit form.
3) If there's one multipart/form-data encoded form using WOFileUpload on a page, then EVERY form on the page must be the same. Other ordinary forms will refuse to process if there's a WOFileUpload on the page unless they are also multipart/form-data encoded. And multipart/form-data encoded forms MUST have a file upload in them, or they won't process either.
4) streamToFile on Solaris will sometimes refuse to write to the chosen location, for no good reason. For me, this was due to permissions, and didn't exhibit if the process was running as root. But Aleksey reports different behavior.


It's very frustrating.

--Jonathan


cheers,
aleksey

Okay, the new WOFileUpload is starting to really make me mad. It seems to
be incredibly buggy. Here's what appears to me to be a bug. I would much
appreciate it if someone else could confirm it.

I am running on Solaris. The process is running as the user 'webob'.
There
is a directory, /usr/local/apache/htdocs/.  Now, /usr, /usr/local/, and
/usr/local/apache are NOT writeable by the 'webob' user. However,
/usr/local/apache/htdocs/ IS writeable by the webob user.  If I use
java.io.File.createNewFile() I can succesfully create a file inside
/usr/local/apache/htdocs without any problems at all----in my same test
app, running as the user 'webob'.

However, WOFileUpload refuses to upload there. If I instruct it to upload
there, after the upload the 'finalFilePath' binding is set to a path in the
/var/tmp directory, and indeed this is where I find the file. No exceptions
are generated, and even turning on FULL debugging with NSLog, no debug
messages are generated at all!  There is definitely no conflict with an
existing file--I am making sure to try file paths that do not already have
a file there.

If instead I try to upload a file to a directory where the 'webob' user has
write permissions to every single directory along the path (for example,
/var/tmp), then the upload works as expected, and the finalFilePath matches
my chosen streamToFilePath binding exactly.  This is what makes me suspect
that WOFileUpload is eroneously refusing to upload a file to a directory
unless the process has write permissions on EVERY directory in the
filepath. This is not how unix permissions work though, I don't need write
permissions like that to write to the actual leaf directory, and I can use
java.io.File to write there myself without a problem.

So if anyone can confirm this, that would be great.  But WOFileUpload is
really starting to enfuriate me. I had already encountered three to four
bugs that were not show stoppers, that I was able to work around. But this
one is a show stopper.  I can not easily work around it without
compromising the security of my server.  This is stupid.  I am not
confident about the thoroughness that Apple tests this stuff before sending
it out the door. I feel like I should be getting paid by Apple for spending
my time finding these bugs; but the real problem is that I can't get my app
to work properly. I really need the streaming API provided in 5.2.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: WOFileUpload ANOTHER bug (From: Aleksey Novicov <email@hidden>)

  • Prev by Date: RE: Formatting table resultset
  • Next by Date: Re: VARCHAR > 3000 characters with JTurbo and SQL Server 7 (WO 5.2)
  • Previous by thread: Re: WOFileUpload ANOTHER bug
  • Next by thread: Re: WOFileUpload ANOTHER bug
  • Index(es):
    • Date
    • Thread