Issue 4179: Use of Directory in transfer/insert/append/delete operations (ftamftp-ftf) Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: The interface Directory derives from File and can therefore be used as an argument in FileTransferSession::transfer/insert/append/delete calls. Directories are only mentioned in the description of delete. Is the delete of a directory recursive or must the directory be empty first? And what is the behavior of transfer,insert,append when one or both of the arguments are Directories? Is this legal at all? Action Requested: Specify behavior when a Directory is used as src or dest argument to transfer,insert, and append. Specify recursive behavior for those operations and delete. Resolution: see above Revised Text: The new IDL interfaces are documented Section 3.1.4 FileSystemEntry Interface, Section 3.1.5 Directory Interface, and Section 3.1.7 File Interface. Actions taken: January 30, 2001: received issue Discussion: Resolution Changed the IDL such that Directory no longer derives from File and cannot be used in any of these operations due to the ambiguity. Both File and Directory derive from a base interface FileSystemEntry that provides common operations for things such as get_name. End of Annotations:===== Date: Tue, 30 Jan 2001 17:02:24 +1000 From: Ted McFadden To: issues@omg.org, ftamftp-ftf@omg.org Cc: tmcf@ooc.com.au Subject: ftam/ftp issue: Semantics of transfer/insert/append for Directories Message-ID: <20010130170224.D15721@ooc.com.au> Reply-To: Ted McFadden Mail-Followup-To: issues@omg.org, ftamftp-ftf@omg.org Mime-Version: 1.0 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id AAA08445 for ; Wed, 31 Jan 2001 00:52:59 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id AAA16813 for tmcf@ooc.com.au; Wed, 31 Jan 2001 00:52:59 +1000 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id RAA07379 for ; Tue, 30 Jan 2001 17:02:24 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id RAA16378 for tmcf@ooc.com.au; Tue, 30 Jan 2001 17:02:24 +1000 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: Tb[!!>j9e9!O0e9kA/!! Hi, ftam/ftp issue: Use of Directory in transfer/insert/append/delete operations ------------------------------------------------------------------- The interface Directory derives from File and can therefore be used as an argument in FileTransferSession::transfer/insert/append/delete calls. Directories are only mentioned in the description of delete. Is the delete of a directory recursive or must the directory be empty first? And what is the behavior of transfer,insert,append when one or both of the arguments are Directories? Is this legal at all? Action Requested: Specify behavior when a Directory is used as src or dest argument to transfer,insert, and append. Specify recursive behavior for those operations and delete. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill 4169, QLD. Australia > #4179: Whether or not a Directory can be recursively > deleted is a protocol (and implementation) dependant > issue. If the underlying protocol (or variation > thereof) supports recursive deletion, the operation > will be successful. If not, an > IllegalOperationException will be raised. Similarly > with transfer/insert/append. If a restriction must be > put on these operations to exhibit uniform behaviour > for all protocols, then these operations should not be > recursive (lowest common denominator). > Even if the underlying protocol does not support recursion, a virtual file system can provide it on top of the protocol. Whether this is desired or should be required is another question entirely. Leaving this implementation dependent does have the down-side that clients no longer have an interface that they can use in a uniform manner, if each implementation may or may not allow various operations involving directories. The spec should be explicit, even if all it says is this is an implementation specific matter, clients must not rely on the use of Directory or recursion in any of these operations.