Mail Archives: cygwin/2002/12/23/21:36:31
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:<path>" 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/
- Raw text -