[Bf-committers] UNC shares getting closer to working
harley.acheson at gmail.com
Wed Aug 14 01:52:11 CEST 2013
My worry with requiring long UNC is that in my experience not many people
are familiar with it, even amongst those that are familiar with regular UNC
If you are going to require the use of something fairly obscure, you might
as well use something *better*. Use a URI instead.
so for a unc path you would require this form:
and even drive-mapped paths could use:
using a URI with a scheme like this, it means that we can (eventually)
other schemes like http, https, dav, ftp, file, afp, beshare, content, etc
and again, does not collide with the Blender use of \\ as none of the above
support relative paths.
On Tue, Aug 13, 2013 at 4:31 PM, W. Nelson <indigitalspace at yahoo.com> wrote:
> Anything workable even though it's maybe not ideal will let the show go
> one for a lot of people more than being a show stopper for a lot of people.
> *From:* Harley Acheson <harley.acheson at gmail.com>
> *To:* W. Nelson <indigitalspace at yahoo.com>; bf-blender developers <
> bf-committers at blender.org>
> *Sent:* Tuesday, August 13, 2013 4:16 PM
> *Subject:* Re: [Bf-committers] UNC shares getting closer to working
> Another option, although I'm not really recommending it, is to *require*
> the long
> form of UNC, which won't collide with Blender's use of \\
> So instead of using \\computer\sharename\path\file.blend
> you require this form:
> Doing this also means that you can use paths longer than 259 character
> in Window XP. In fact, if you want to use really long paths under XP you
> even want to allow drive-mapped files in this format as well:
> Obviously this form still has the double-backslash, but it is always
> followed by
> a "?\" which will not occur anywhere else, so just check for \\?\ and
> it is a windows long UNC.
> On Tue, Aug 13, 2013 at 3:23 PM, W. Nelson <indigitalspace at yahoo.com>wrote:
> I have been discussing the UNC shares fix with Elubie. She has a quick
> fix that addresses most of the issues.
> One of the biggest remaining issues is the use of the double hack use for
> .blend path versus network location handling UNC. This is a bit tricky
> since there is no uniform file handling routine or module in Blender for
> all code to use. It is handled by multiple tailored code segments in
> different parts of the codebase.
> In the tricky context of it possibly being a UNC or .blend path I propose
> that those routines check a user preference before proceeding. This will
> be default \\ UNC off and tickable to on. Or maybe put and operator in
> the File>External Data menu somehow to establish this and maybe save with
> individual files.
> Therefore the user/studio can determine in those circumstances if it wants
> to use \\ as UNC instead of .blend path. Obviously it will have to
> establish a business rule amongst its workforce that the choice is don't
> use \\ as a .blend path shortcut. Of course 3rd party addon use will also
> have to be considered.
> The other logic fix is evaluate as a .blend path as usual but if there is
> an error or a detectable discrepancy in loading/saving then evaluate as a
> UNC path next to see if a the discrepancy is resolved, then if error, fail
> out if need be. This would work for missing files on load or missing file
> path segments on save. So in cases where Blender would make a path, it
> would check first to see if there is a valid UNC path of the same
> reference. If so, it would use that instead of making a path locally where
> the .blend file is.
> These types of fixes could be worked to fix existing code and then there
> should be a coding standard set that subsequent merges/patches will adhere
> to this standard since a standard file i/o module is not very realistic at
> this point.
> This should give a fairly good workable system for those that want to use
> UNC shares
> Existing patch tracker ticket:
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers