RE: Stopping the physical removal of empty folders...
Hello Jeff, Are you using ACLs feature? It would be easy to do what you want by denying write permissions to the folder you want to protect. Hope this helps, Miguel Figueiredo -Original Message- From: Jeff Hillier [mailto:[EMAIL PROTECTED] Sent: sábado, 16 de Junho de 2007 1:13 To: slide-user@jakarta.apache.org Subject: Stopping the physical removal of empty folders... Hi All- I've been using slide for some time now with a FileStore (linux) and a J2EE Store (backed by an Oracle DB). Currently when I delete all the files from a folder, the physical folder is removed from the file system. This is ok for most of my folders, but I have a few specific cases where if a folder has no files in it, I still need the folder to exist on the file system... Short from adding a file that can't be deleted to the folder, how can I keep certain folders from ever being deleted once they have been created...? Does the recursive delete happen in the content store? or is it a result of some other action? any info on where to start looking would be greatly appreciated.. Thanks Jeff - 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]
RE: Stopping the physical removal of empty folders...
Miguel- Thanks for getting back to me.. I am using ACL's to control access but I'm not sure that will help.. The real problem isn't that the user has access to delete the folder, that part is done. The problem is that when all the files in the folder are gone, the folder is still present in the metadata slide keeps, so it shows up accessing it, but it isn't present on the underlying file system. The folder in question is required to be present on the file system for external applications.. If there is at least one file in the folder all is well, remove all the files and slide removes the folder from the file system because its empty but to the slide end user it appears as if it still exists... Jeff At 01:40 AM 6/18/2007, you wrote: Hello Jeff, Are you using ACLs feature? It would be easy to do what you want by denying write permissions to the folder you want to protect. Hope this helps, Miguel Figueiredo -Original Message- From: Jeff Hillier [mailto:[EMAIL PROTECTED] Sent: sábado, 16 de Junho de 2007 1:13 To: slide-user@jakarta.apache.org Subject: Stopping the physical removal of empty folders... Hi All- I've been using slide for some time now with a FileStore (linux) and a J2EE Store (backed by an Oracle DB). Currently when I delete all the files from a folder, the physical folder is removed from the file system. This is ok for most of my folders, but I have a few specific cases where if a folder has no files in it, I still need the folder to exist on the file system... Short from adding a file that can't be deleted to the folder, how can I keep certain folders from ever being deleted once they have been created...? Does the recursive delete happen in the content store? or is it a result of some other action? any info on where to start looking would be greatly appreciated.. Thanks Jeff - 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]
RE: Stopping the physical removal of empty folders...
Hello Jeff, That is an interesting behavior which I was not expecting. It should be implementation specific of the TxStore all right, although I never looked into that code. Miguel -Original Message- From: Jeff Hillier [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 18 de Junho de 2007 17:55 To: Slide Users Mailing List Subject: RE: Stopping the physical removal of empty folders... Miguel- Thanks for getting back to me.. I am using ACL's to control access but I'm not sure that will help.. The real problem isn't that the user has access to delete the folder, that part is done. The problem is that when all the files in the folder are gone, the folder is still present in the metadata slide keeps, so it shows up accessing it, but it isn't present on the underlying file system. The folder in question is required to be present on the file system for external applications.. If there is at least one file in the folder all is well, remove all the files and slide removes the folder from the file system because its empty but to the slide end user it appears as if it still exists... Jeff At 01:40 AM 6/18/2007, you wrote: >Hello Jeff, > > Are you using ACLs feature? It would be easy to do what you want by denying >write permissions to the folder you want to protect. > >Hope this helps, >Miguel Figueiredo > >-Original Message- >From: Jeff Hillier [mailto:[EMAIL PROTECTED] >Sent: sábado, 16 de Junho de 2007 1:13 >To: slide-user@jakarta.apache.org >Subject: Stopping the physical removal of empty folders... > >Hi All- > >I've been using slide for some time now with a FileStore (linux) and a J2EE >Store (backed by an Oracle DB). > >Currently when I delete all the files from a folder, the physical folder is >removed from the file system. This is ok for most of my folders, but I have >a few specific cases where if a folder has no files in it, I still need the >folder to exist on the file system... > >Short from adding a file that can't be deleted to the folder, how can I >keep certain folders from ever being deleted once they have been created...? > >Does the recursive delete happen in the content store? or is it a result of >some other action? > >any info on where to start looking would be greatly appreciated.. > > >Thanks > >Jeff > > > >- >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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]