This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Perl package File::Spec confused under cygwin


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]