Re: double dots are not allowed in filenames?

On Wed, Aug 29, 2007 at 01:10:47AM +0300, Yitzchak Gale
wrote:
> I wrote:
> >> rcp... man page says:
> >>    Each file or directory argument is
> >>    either a remote file name of the form
``rnamerhost:path'',
> >>    or a local file name
> >>    (containing no `:' characters, or a `/'
before any `:'s).
> >> Perhaps darcs should follow that convention.
> 
> David Roundy wrote:
> > Yeah, checking for '/' before ':' would make a lot
of sense.
> 
> >> How does darcs distinguish a URL from an
rcp-style
> >> remote file?
> >> ...Am I correct that not every legal URL
conforming
> > > to RFC 3986 can be accepted?
> 
> > Don't URLs always have :// in them?
> 
> No. But I think it is reasonable for darcs to
recognize
> only those that do. So that answers both of my
> questions.
> 
> >> ..."file:" URLs are allowed to
> >> contain ':'. Does darcs support this?
> 
> > In the original poster's situation, any URL is
invalid,
> > and it's a pure and simple darcs bug.
> 
> Well, OK, but what is the correct behavior?
> 
> I propose the following algorithm:

I agree, except for one bit (see below)

> In contexts where only local paths make sense,
> we interpret every file spec as a local path.
> (Can that include UNC paths on Windows?
> It would be nice.)

I'm not sure what an UNC path is on windows.

Note, implementing this will require a rather extensive code
review.
Eric's put together some code implementing specific data
types that
are intended to describe what sort of object a given String
is.  I think
switching functions over to use a "LocalPath" type
when this is what is
intended should fix this.  Then when reading a
"LocalPath" we'll never try
to treat it as a URL.

> Otherwise:

In this case, I think we should have a "UrlPath"
data type, which could be
any of the below.  We use UrlPaths almost exclusively for
identifying
(possibly remote) repositories, but also (of course) for
accessing files
within a repository.

Along the way, we might find it helpful to refactor
Repository into two
types: ReadableRepository and LockedRepository (which is
writeable), with
the latter holding a LocalPath describing its absolute
path.

> 1. If a file spec begins with a valid URI scheme
> name followed by "://", it is a URL.
> 
> 2. If it contains a ':' that is not after a '/', then
it is
> an rcp-style remote file. (Even on Windows,
> for consistency.)

On windows, I think we should treat c:/path/to... as a local
path (i.e. c
is the drive letter).  If someone really has a one-character
hostname, they
can always use a fully-qualified domain name for their scp
path.

> 3. Otherwise, it is a local file path (or UNC on
> Windows).
> 
> Note that according to RFC3986, a valid URI
> scheme name is:
> 
> scheme      = ALPHA *( ALPHA / DIGIT / "+" /
"-" / "." )
-- 
David Roundy
http://www.darcs.net
_______________________________________________
darcs-users mailing list
darcs-usersdarcs.net

http://lists.osuosl.org/mailman/listinfo/darcs-users

I wrote:
>> (Can that include UNC paths on Windows?
>> It would be nice.)

David Roundy wrote:
> I'm not sure what an UNC path is on windows.

They look like:

\host-nameshare-namerest-of-path

Whenever someone designates a folder as
"shared" and gives it a share name, others
within the local Windows network (domain
or workgroup) can use the folder in this way
wherever a local path can be used. I guess
it is kind of like an nfs mount in some sense.

Unfortunately, these things behave badly whenever
there are any network problems, and apps tend
to hang in that case. Oh well. Anyway, I think
Windows users would like this to work as expected
(i.e., nice when things are good, hang otherwise).

Note that Windows "drive letters" have this same
bad behavior, because you can assign a drive
letter to a share.

> On windows, I think we should treat c:/path/to...
> as a local path (i.e. c
> is the drive letter).

Good idea. Drive letter path semantics are embedded
deep in the psyche of Windows users. rcp-style remote
paths are foreign to them.

> If someone really has a one-character hostname, they
> can always use a fully-qualified domain name for their
scp path.

Perhaps we should also support "scp:" and/or
"sftp:"
URLs.

I just noticed that the IETF has abandoned all plans
to recognize this type of URL, or anything else related
to SSH. It appears that the SSH approach is becoming
deprecated, in favor of security wrappers around other
protocols.

It probably would be a good idea to add support for
something like WebDAV to darcs - meaning you could
also darcs push/put to http:// and https://.
libcurl has support for WebDAV, so maybe it's not
a big deal to add.

Most people nowadays are more comfortable with
WebDAV than SSH. I personally prefer SSH,
but it becomes an issue with other members of
my team.

Regards,
Yitz
_______________________________________________
darcs-users mailing list
darcs-usersdarcs.net

http://lists.osuosl.org/mailman/listinfo/darcs-users