[Bf-committers] UNC shares getting closer to working

[Harley Acheson]

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:

\\?\UNC\computer\sharename\path\file.blend

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
might
even want to allow drive-mapped files in this format as well:

\\?\D:\path\file.blend

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 assume
it is a windows long UNC.

Harley





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:
>
> https://projects.blender.org/tracker/index.php?func=detail&aid=21836&group_id
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>