I know my client implementation would benefit from this fix... And Stefan, the guy with 240000 files in his Slide load test, will probably need it too if the repository is to be that large :-)
Warwick ----------------------------------------------------------- Warwick Burrows E2open Senior Engineer 9600 Great Hills Trail, #325 http://www.e2open.com Austin TX 78759 ----------------------------------------------------------- -----Original Message----- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:25 AM To: Slide Users Mailing List Subject: Re: Deleting collection leaves physical dirs in place? James is right! The original implementation recursed down on empty folders and deleted them - ofter a bit too much. As I though no one would bother I simply commented out the code. If this causes any problems I will find another solution. Actually, this should be simple... Oliver James Mason wrote: > There's a comment in the source that suggests deleting directories can > lead to accidentally deleting the root directory. The code for deleting > directories is then commented out. > > -James > > Warwick Burrows wrote: > >> >> Oh. That's interesting. Are the unused physical directories ever >> deleted? I >> don't understand how keeping the old directories around can be >> beneficial. >> All they will do is take up space in the inode table/FAT and make >> searching >> for a particular directory slower over time as the number of defunct >> directories builds up. Does deleting the defunct directory break the >> implementation in some other way?? >> >> Thanks, >> Warwick >> >> >> >> ----------------------------------------------------------- >> Warwick Burrows E2open >> Senior Engineer 9600 Great Hills Trail, #325 >> <http://www.e2open.com/> http://www.e2open.com Austin TX 78759 >> ----------------------------------------------------------- >> >> -----Original Message----- >> From: Kiran Patchigolla [mailto:[EMAIL PROTECTED] Sent: >> Monday, August 02, 2004 8:47 PM >> To: 'Slide Users Mailing List' >> Subject: RE: Deleting collection leaves physical dirs in place? >> >> >> >> I believe this is how it is designed. See attached.. >> >> >> >> >> _____ >> >> From: Warwick Burrows [mailto:[EMAIL PROTECTED] Sent: >> Monday, August 02, 2004 6:33 PM >> To: 'Slide User Group ([EMAIL PROTECTED])' >> Subject: Deleting collection leaves physical dirs in place? >> >> >> >> Hi, >> >> >> >> Has anyone else seen a problem where deleting a collection will >> delete >> all >> the metadata for the collection and delete the files under that >> collection >> but not the physical directory structure itself? I'm using Slide >> 2.1M1 and >> using both the CLI and my application have found that the recursive >> delete >> of a collection seems to only half-work. To reproduce create a collection >> with the CLI then drop a file under it. Delete the collection. An "ls" >> command from the CLI will show that the collection and its children have >> been deleted but looking at the physical filesystem shows that the >> collection structure has not been deleted although the files within have. >> I'm using a combination of stores with the TX filesystem for the >> contentstore and a JDBC store for every other store type. >> >> >> >> Thanks, >> >> Warwick >> >> >> >> >> <http://www.e2open.com/> >> >> _____ >> >> Warwick Burrows Senior Software Engineer >> >> >> Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Fax: >> 512.343.8727 >> >> >> >> 9600 Great Hills Trail, #325 Austin, TX 78759 http://www.e2open.com >> <http://www.e2open.com/> >> >> _____ >> >> >> >> >> >> ********************************************************************* >> *** >> >> If you have received this e-mail in error, please delete it and >> notify >> the >> sender as soon as possible. The contents of this e-mail may be >> confidential >> and the unauthorized use, copying, or dissemination of it and any >> attachments to it, is prohibited. >> Internet communications are not secure and Hyperion does not, therefore, >> accept legal responsibility for the contents of this message nor for any >> damage caused by viruses. The views expressed here do not necessarily >> represent those of Hyperion. >> >> For more information about Hyperion, please visit our Web site at >> www.hyperion.com >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
