From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,24a59fbc07128ff8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-09 15:57:11 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Beard, Frank" Newsgroups: comp.lang.ada Subject: RE: rename missing in Text_IO Date: Wed, 9 May 2001 18:56:12 -0400 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: avanie.enst.fr 989449028 97878 137.194.161.2 (9 May 2001 22:57:08 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Wed, 9 May 2001 22:57:08 +0000 (UTC) To: "'comp.lang.ada@ada.eu.org'" Return-Path: X-Mailer: Internet Mail Service (5.5.2448.0) Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.3 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: newsfeed.google.com comp.lang.ada:7416 Date: 2001-05-09T18:56:12-04:00 -----Original Message----- From: Fraser Wilson [mailto:blancolioni@blancolioni.org] >> But if what we are considering is what an Ada Library Package >> should look like, then there's no reason to copy the low level >> features of an operating system. And the semantics of the mv >> command is generally superior. A program should not need to >> know the details of the disk layout. > The problem is that a rename or move on the same disk is significantly > cheaper than one that crosses disks. It's also a much safer > operation. So what? If I need to move it to another disk, then I need to move it to another disk. I don't think the cost would be the issue in that case. If cost is the issue, which would be determined either by prototyping or performance testing, then keep it on the same disk. > I think the implementation detail line is quite fuzzy here. POSIX figured it out in some reasonable manner. > More generally, the destination might not even be a disk filesystem; > it could be a remote ftp site or /proc on Linux. Does a move/rename > even make sense in those cases? You wouldn't be using the move/rename in this case anyway, would you? Probably an RPC command, which is another Annex for discussion. Frank