Bugzilla – Bug 3580
Directory removal not working
Last modified: 2005-07-19 14:54:51
You need to log in before you can comment on or make changes to this bug.
I'm having problems deleting directories with the trunk code (haven't tried the 4.0 branch). I get the following debug output, but the directory has not been deleted: 2005-07-19 11:07:42,017 DEBUG database.ReliableFileTransferDbAdapter [Thread-36,getOverallStatus:1234] OverallStatus for requestId: 30039 Finished:0 Retrying:0 Failed:0 Active:1 Pending:0 Cancelled:0 2005-07-19 11:07:42,018 DEBUG service.TransferWork [Thread-36,statusChanged:171] [Request 30039, Transfer 53542] setting overall rp to (finished: 0, active: 1, failed: 0, restarted: 0, pending: 0, cancelled: 0) 2005-07-19 11:07:42,048 DEBUG service.DeleteClient [Thread-36,delete:149] Deleting a directory /home/lane/.globus/scratch/6d817745-c963-4125-6821-c6fc5d545a4a/ 2005-07-19 11:07:42,118 DEBUG service.DeleteClient [Thread-36,delete:168] This dir: /home/lane/.globus/scratch/6d817745-c963-4125-6821-c6fc5d545a4a/ is deleted 2005-07-19 11:07:42,118 DEBUG service.TransferWork [Thread-36,processStates:465] [Request 30039, Transfer 53542] processing state for transfer of gsiftp://logan:2811/home/lane/.globus/scratch/6d817745-c963-4125-6821-c6fc5d545a4a/ -> null 2005-07-19 11:07:42,118 DEBUG service.TransferWork [Thread-36,processStates:475] [Request 30039, Transfer 53542] transfer done
I just tried this with the globus_4_0_branch code and am having the same problem: logan% ls ~/.globus/scratch/ logan% /usr/local/globus/globus-4.0.1/bin/globusrun-ws -submit -factory logan -submission-id uuid:6d817745-c963-4125-6821-c6fc5d545a4a -staging-delegate -streaming -job-description-file /tmp/lane/jdl-zTmOVv.xml Delegating user credentials...Done. Submitting job...Done. Job ID: uuid:6d817745-c963-4125-6821-c6fc5d545a4a Termination time: 07/20/2005 17:21 GMT Current job state: StageIn Current job state: Active Current job state: CleanUp-Hold Tue Jul 19 11:21:21 MDT 2005 Current job state: CleanUp Current job state: Done Destroying job...Done. Cleaning up any delegated credentials...Done. logan% ls ~/.globus/scratch/ 6d817745-c963-4125-6821-c6fc5d545a4a/ Here is the job description I'm using: logan% cat /tmp/lane/jdl-zTmOVv.xml <job> <executable>/bin/date</executable> <directory>/${GLOBUS_SCRATCH_DIR}/6d817745-c963-4125-6821-c6fc5d545a4a/</directory> <stdout>/${GLOBUS_SCRATCH_DIR}/6d817745-c963-4125-6821-c6fc5d545a4a/out.15862</stdout> <stderr>/${GLOBUS_SCRATCH_DIR}/6d817745-c963-4125-6821-c6fc5d545a4a/err.15862</stderr> <fileStageIn> <transfer> <sourceUrl>gsiftp://logan/tmp/lane/empty/</sourceUrl> <destinationUrl>file:///${GLOBUS_SCRATCH_DIR}/6d817745-c963-4125-6821-c6fc5d545a4a/</destinationUrl> <attempts>5</attempts> </transfer> </fileStageIn> <fileCleanUp> <deletion> <file>file:///${GLOBUS_SCRATCH_DIR}/6d817745-c963-4125-6821-c6fc5d545a4a/</file> </deletion> </fileCleanUp> </job>
I just ran a simple test with rft command line client to delete a dir and it worked. I verified the notification is sent correctly. What version of gridftp server are you using ?
I think Peter was using pre 3.9.5 gridftp server that did not support recursive directory delete. For those servers RFT deletes all the files in the directory but the dir structure remains intact.
A rebuild of the GridFTP server from the trunk solved the problem.
