commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark A Fortner <>
Subject Re: Upload ownership problems
Date Tue, 25 Jul 2006 23:59:32 GMT
You might try Slide (  It's a WebDAV servlet that has support
for user permissions.  Windows users can mount the volume using the file explorer and Mac
users can use the Finder.

Hope this helps,


Troy Davis <> wrote: Hello,

I recently switched from a commercial upload bean to commons- 
fileupload, and am very happy with its performance except in one  
respect: File ownership rigidity. We're running Tomcat 5.5 with about  
25 contexts (our clients). Tomcat is being run by root, so all of my  
upload directories must be owned by root for the upload to work for  
some reason. But at the same time, I need to allow users to use an  
FTP client to upload really large files, or delete old files that are  
no longer used. If the file was uploaded via http (using fileupload),  
this is not possible because the uploaded file will be owned by root.

I've thought about several possible solutions, but they all have  
unwanted side effects:

1. Run a cron script to chown all files to root.user periodically,  
chmod g+w as well. The problem here is immediacy, FTP access to any  
files uploaded through a client's website will be owned by root.root,  
they won't be able to delete the file until the script runs next.

2. Set each Tomcat context to run as a different user. Sounds like  
the best approach, apache can do this, but I can't find any info on  
how to do it with Tomcat. Is this even possible?

3. Write a file manager app. This would eliminate the need for FTP  
access, but it would take a considerable amount of time to write the  
file manager app, test it and deploy.

How have other fileupload users dealt with this problem?

Thank You,

To unsubscribe, e-mail:
For additional commands, e-mail:

Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message