Using a XFS filesystem makes FileStorageService.deleteResource behave differently from Ext4

[hsilva-keep]

This happens when trying to delete default objects created the first time RODA is initialized (by selecting the root AIP and hitting Remove). And it doesn't happen when using Ext4 filesystem.

2016-08-26 17:25:55,768 [ajp-nio-8009-exec-9] INFO  o.r.c.storage.fs.FileStorageService - Moving to trash: /apps/KEEPS/roda/data/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b to /apps/KEEPS/roda/data/tra
sh/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b
2016-08-26 17:25:55,770 [ajp-nio-8009-exec-9] INFO  o.r.c.storage.fs.FileStorageService - Re-trying to move to trash: /apps/KEEPS/roda/data/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b to /apps/KEEPS/ro
da/data/trash/e0ff1a9f-3e20-4e3f-a5c6-33da32aec71e/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b
2016-08-26 17:25:55,772 [ajp-nio-8009-exec-9] ERROR o.r.c.storage.fs.FileStorageService - Error moving to trash: /apps/KEEPS/roda/data/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b to /apps/KEEPS/roda/da
ta/trash/e0ff1a9f-3e20-4e3f-a5c6-33da32aec71e/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b
org.roda.core.data.exceptions.AlreadyExistsException: Cannot copy because target path already exists: /apps/KEEPS/roda/data/trash/e0ff1a9f-3e20-4e3f-a5c6-33da32aec71e/storage/aip/8faeaf8c-9a1f-49cc-a239-f34
10d8bc13b
        at org.roda.core.storage.fs.FSUtils.move(FSUtils.java:119)
        at org.roda.core.storage.fs.FileStorageService.trash(FileStorageService.java:186)
        at org.roda.core.storage.fs.FileStorageService.deleteResource(FileStorageService.java:418)
        at org.roda.core.model.ModelService.deleteAIP(ModelService.java:431)
        at org.roda.wui.api.controllers.BrowserHelper.deleteAIP(BrowserHelper.java:1034)
        at org.roda.wui.api.controllers.Browser.deleteAIP(Browser.java:670)
        at org.roda.wui.server.browse.BrowserServiceImpl.deleteAIP(BrowserServiceImpl.java:295)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:587)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:333)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:303)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373)
        at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:614)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
        at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
        at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:868)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.DirectoryNotEmptyException: /apps/KEEPS/roda/data/storage/aip/8faeaf8c-9a1f-49cc-a239-f3410d8bc13b
        at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:498)
        at sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
        at java.nio.file.Files.move(Files.java:1395)
        at org.roda.core.storage.fs.FSUtils.move(FSUtils.java:117)
        ... 38 common frames omitted

[hsilva-keep]

From Files.move Java docs, we get the following intel:
... This method may be invoked to move an empty directory. In some implementations a directory has entries for special files or links that are created when the directory is created. In such implementations a directory is considered empty when only the special entries exist. When invoked to move a directory that is not empty then the directory is moved if it does not require moving the entries in the directory. For example, renaming a directory on the same FileStore will usually not require moving the entries in the directory. When moving a directory requires that its entries be moved then this method fails (by throwing an IOException). To move a file tree may involve copying rather than moving directories and this can be done using the copy method in conjunction with the Files.walkFileTree utility method.

Meaning, we need to have a fallback for filesystems where moving a non-empty directory implies also moving its entries (as it seems to be the case of XFS, whereas Ext4 behaves nicely).

[hsilva-keep]

Done since 3956216 (with this commit the solution was redone by implementing a recursive move instead of a copy followed by a delete).