Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "linda w \(cyg\)" To: Cc: "'Michael A Chase'" Subject: RE: Perl package File::Spec confused under cygwin Date: Mon, 23 Dec 2002 18:35:49 -0800 Message-ID: <004e01c2aaf5$2b751cc0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id gBO2aVe28659 This may be somewhat arcane/tedious, but... > > But Unix does have a concept of a mount point (device) and > > path from the mount point. Conceivably, one could view the mount > > point itself as a local host name for the "volume" (local, > remote or a > > device) with path being location on the mounted fs. > > device != volume. For the purposes of File::Spec, it would > be better to leave the directory structure as a single tree. --- I agree the current functionality is useful. It is likely what I would usually need, but I don't recall a purpose statement that wouldn't equally apply to thinking of other OSs', 'volumes', as simply part of the path. For example, I want to create another file in the same subdirectory with a different extension, splitting out volume would seem unuseful. In fact, if I choose, say, in Windows, to think of "D:" merely as a 'shortcut', to a predetermined directory (set by chdir), and regard D: as a path component, where d:windows decomposes to dirname=d:, basename=windows, then one could argue that "D:" is merely another type of "dir" component and should be viewed equivalently in cases where filesystem (or volume) is unimportant. I can't think of any examples where I want the volume separate from the pathname except in those cases where I also want an undifferentiated path in unix. However, in examples where I think I want a 'volume' or 'mount-point', (as in implementing a 'mv' function), I also need to know the same information in unix. i.e -- if manip filename in same dir, I want them together, else if I want to copy or move to a different dir, I need to know whether 'ln' or 'cp' semantics need to be used -- which means, OS independent, I need to know if they are on a separate FS. Forget what you know about unix for a second. In OS's, what does 'volume' usually mean? Isn't it an independent file system that can be referenced via an OS and user dependant identifier? Why wouldn't that apply to unix? > If you submit a Perl bug report with a patch that does what > you want and explains why you want it, it is likely to get > included in the next release of Perl. If you talk nice to > Gerrit, you may even get it in the next build of Cygwin Perl > pending a change to the base source. Borrowed code from > File/Spec/Win32.pm may provide a start. --- Yeah. Don't get me wrong. I need the functionality currently provided, but just like with 'mv', I also need to know if a target requires me to issue a 'rename' or a 'copy'. I may be wrong, can you think of many (or any) situtations where you'd want to know about a 'volume', separately, on another OS, where you wouldn't also want to know parallel 'fs' information? Ultimately, to implement a 'mv', some determination needs to be made to get the absolute OS-internal device numbers since it is always possible that you are copying from the same device to the same via a different mount point and theoretically, that should be handled as a "create new link, remove old link" operation instead of a physical file copy. I might propose to a perl audience that the default case should be to treat 'volume' as 'fs-mount-point' in unix to provide equivalent functionality to other OS's and that a special case be setup for where you don't care about volume and just want "file-prefix" + "separator" + "basename". I suppose this is potentially a philosophical question that may need discussion at the Perl monastery by and with a bunch of Perl monks... :-) -l -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/