Comments on: File paths for windows servers

Ok, time to chat about this, as BrianH has posted bug#1115.

We need to be able to easily access Windows file servers from Windows systems. The to-local-file function wasn't converting file paths properly, and it has been modified for the next release.

Here is the test pattern for it:

[""       = to-local-file %""]
["\"      = to-local-file %/]
["\"      = to-local-file %//]
["c:\"    = to-local-file %/c]
["c:\"    = to-local-file %/c/]
["c:\d"   = to-local-file %/c/d]
["c:\d\"  = to-local-file %/c/d/]
["\\host" = to-local-file %/host]
["\\host\" = to-local-file %/host/]
["\\host\d" = to-local-file %/host/d]
["\dir"   = to-local-file %//dir]
["\dir\d" = to-local-file %//dir/d]

This should be consistent with R2. Of course, note that single character root names are expected to be drive letters and convert to the ":" format. I don't think there's much we can do about that (remember, we really try to stay OS-independent when possible.)

We will want to do a similar conversion for file URLs, but allow an extra slash.

Post your inputs because this will be frozen soon.

8 Comments

Comments:

Brian Hawley 21-Jul-2009 15:41:53	Looks good to me. I particularly like how it doesn't replicate the bug in R2 where trailing slashes are improperly removed (tests 7 and 9). I presume that this is a shortcut for accessing Windows servers from Windows, using the login credentials of the current user. Any changes from that could be handled by an smb:// scheme, as per #1121, to be done later.
Peter Wood 21-Jul-2009 22:53:08	If you're adding this Windows specific code to R3, why is the inclusion of the "~" (User's Home Directory in Unix) dismissed on the grounds that it's not cross-platform? See bug report #642.
Brian Hawley 22-Jul-2009 3:35:21	Bug#642 was not dismissed, it was marked as a problem. There is no reason that the ~ extension would need to be Unix-specific - other platforms have user home directories too. It is intended to implement that ability on all platforms. The only thing we dismissed was the idea of implementing it on only Unix platforms - and we dismissed that limitation definitively. However, the system/user object was removed from R3, so we need a new place to put the old system/user/home option. The location system/options/user-home has been suggested in bug#707. Until that suggestion is implemented, bug#642 and many other features are blocked.
Robert 22-Jul-2009 9:47:37	Well, making an implicit assumption that single letters are drive letters can (as all implicit assumption) become problematic. Why not make it explicit? to-local-file %:host/d I have seen a lot of corporate networks where a share is given a single letter to keep the feeling for the user to work on a local drive.
Peter Wood 22-Jul-2009 9:52:31	There is no need for a new place to put the old system/user/home option to support "~" in Unix files names. I ask again, if you are introducing Windows specific code to R3, why can you not add Unix specific code?
Brian Hawley 22-Jul-2009 11:14:04	Robert, the implicit assumption is that single letters are drive names rather than host names. Single letter shares are just fine. Peter, there is nothing Unix-specific about how Unix shells implement the ~ in filenames. They just get a value from an environment variable - other platforms have environment variables too. That environment variable refers to the user's home directory - other platforms have user home directories too, and environment variables that refer to them. The ~ is even expanded to a regular filename before being passed on to programs, which have no direct support for or need to do ~ expansion. It's a cross-platform concept, and directly corresponds to REBOL's mezzanine file management functions, particularly CLEAN-PATH. The only platform-specific code as far as REBOL is concerned would be that which sets system/options/user-home, and there is no problem with adding that since it could easily be done by the startup code. Code that uses that option though would be strewn throughout REBOL, though mostly in mezz-file.r and mezz-load.r: Mezzanine code. So far we have avoided putting any platform-specific stuff in the mezzanine code, and that is a good thing. Such code is isolated in the natives, preferably in the host code. The situation is different with the above proposal since it would need to be implemented in the file scheme code, which is already platform-specific, and in the host code. If you (personally) really want to add support for ~ expansion to the file scheme for Unix platforms, go right ahead once the host code is released. Keep in mind that your code may never see those ~ characters though, since the mezzanines will be expanding it for everyone before the host code sees anything.
James_nak 25-Jul-2009 17:31:08	Perhaps it's too late but I don't know, I think it's kind of confusing to place one slash and then resolve to two slashes (in some instances only). Wouldn't it be more straight forward to have two slashes equal to two slashes (reversing their direction of course)?
Maxim Olivier-Adlhoch 9-Aug-2009 23:54:04	UNC names are already cross platform... they should not be mangled with... please keep the double slash at the start, its very complicated to build GUIs which must handle mangled // all the time, I've even had client complain about this in the past... furthermore, IMHO this is totally useless: ["\" = to-local-file %//] AFAIK "\" isn't a real windows place... it depends on the "current" directory and is resolved in the applications. the / should show drives, mount points. the // should show local machines on OSes which support machine browsing.

Post a Comment:

You can post a comment here. Keep it on-topic.