Hi Caleb! Thanks for the link, but unfortunately I don't know how to build it. I downloaded it via SVN and run Maven, and got error: [ERROR] Non-resolvable parent POM: Could not find artifact org.xwiki.platform:xwiki-core-parent:pom:2.7-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 27, column 11 -> [Help 2] On Thu, Dec 16, 2010 at 2:34 PM, Caleb James DeLisle <calebdelisle(a)lavabit.com> wrote:

Hi, On Fri, Dec 17, 2010 at 08:49, Donnie Lee <lprpro(a)gmail.com> wrote: You need to setup maven with XWiki repositories, see http://dev.xwiki.org/xwiki/bin/view/Community/Building -- Thomas Mortagne

Here is a copy of the .jar file. You put that file in your /WEB-INF/lib directory (don't worry about the 2.7 in the name it should be compatible) and change your xwiki.cfg file as described earlier. http://www.xwiki.org/xwiki/bin/download/XWiki/Caleb_James_DeLisle/xwiki%2Ds… Attachments which you upload after making this change will be stored on the filesystem (on my computer, they are stored in /var/log/tomcat5.5/work/ in a directory which is created called "storage") If you decide to change back to the old storage, the new attachments will all suddenly become empty. Do not delete anything in that directory manually or add anything, especially not symlinks which would confuse recursive delete code with bad results. There is an occasional problem where an attempt to delete an attachment waits forever. This is because some misbehaving thread has acquired the lock on the attachment file and refuses to let it go. I found that when it occurs, it can be easily fixed by viewing the attachment then trying to delete again. Lock forcing is on my todo list. Please back up your system if there is anything of value, this code has not yet seen any use on a live server. Thanks a lot for testing, I hope you can provide some early feedback. Caleb On 12/17/2010 04:52 AM, Donnie Lee wrote:

Hi Denis, On Mon, Dec 20, 2010 at 14:38, Donnie Lee <lprpro(a)gmail.com> wrote: Caleb explained his rationale for this on item 2. here: http://markmail.org/message/pl7v4sew2ujksrvv Hope this helps, Guillaume

On Dec 21, 2010, at 10:22 AM, Guillaume Lerouge wrote: Personally I have a hard time with it too and I think everyone who uses this will ask this question since it's far from obvious. I wish we could find a better naming scheme. The only issue is nested spaces and for example we could decide that spaces are aggegreated as a single path element: ..../<space or nested spaces here>/attachments/... Or we could decide to use a system like REST to indicate what each part of the path means Or we could have a special treatment when there's a space called "attachments" like rename it to ~attachments for ex, etc Or... Thanks -Vincent