uSync Filepath too long issue (even with use short paths=true)
I have a LARGE Umbraco site we are trying to use uSync with, but have issues because even with the setting to use the short paths, we are still only to get 8 or 9 levels deep, and some or our site is 12-14 levels.
Would it be possible to use a different id for at least the content directories, why not just use the contented or node id, instead of a hash, is there a technical reason that it wouldnt work?
I arrived at the 8 to 9 using the following formula.
The hash for the directory is 22 characters (+1 for the path separator) = 23
the content.config files= 13 characters
the config has this "~/usync/data" = 11 characters
assuming you publish into a "normal site (c:\inetpub\Umbraco) = 18 characters
this means that 11+13+18 = 42 characters of "fixed overhead"
given that the error is related to 260 characters, minus the overhead means we really only have 218 characters to work with.
yeah the id doesn't work because that will be different on each instance, which means if you then try and save on another site, it won't find the existing file to sync too. basically the id has to be 'reconstructable' at either end so can only be something that we know will be set on either end.
I will have a look at what we can do - thinking about it (as i type) i wonder if moving to a level based thing for content might work ?
the reason there is a tree at all is so we ensure the root nodes are there before the childnodes are imported, but if we just put each node in a folder based on its level ( so have Conent/1/2/3/4/nodename.config) - then we might get loads of levels and the existing code might work because it just walks down the folder structure.
that might work, so i will have play and see what works well and if there are any issues with any of the ideas .
How about storing a separate Xml-based file in the root that maps "arbitrary" numbers to node names/hashes. That way you could control the directory names as either hashes or node names; add another setting to allow them to stored "flat" or in a "tree" with the caveat that you can only go x levels deep in the content... the Xml would give you a way to reconcile things, instead of traversing the directories, you would traverse the Xml.
I'd be ok if that mode were only available when using manual for syncing and saving...
i thought about (and started down the road of) the arbitrary root hashes, as was looking at a guid/level folder things - but then realised the order becomes important (as we don't want things importing first just because their guid starts with a 1)
uSync Filepath too long issue (even with use short paths=true)
I have a LARGE Umbraco site we are trying to use uSync with, but have issues because even with the setting to use the short paths, we are still only to get 8 or 9 levels deep, and some or our site is 12-14 levels.
Would it be possible to use a different id for at least the content directories, why not just use the contented or node id, instead of a hash, is there a technical reason that it wouldnt work?
I arrived at the 8 to 9 using the following formula.
The hash for the directory is 22 characters (+1 for the path separator) = 23 the content.config files= 13 characters
the config has this "~/usync/data" = 11 characters assuming you publish into a "normal site (c:\inetpub\Umbraco) = 18 characters
this means that 11+13+18 = 42 characters of "fixed overhead"
given that the error is related to 260 characters, minus the overhead means we really only have 218 characters to work with.
218/23 = 9 levels; assuming my math is correct.
hi ,
yeah the id doesn't work because that will be different on each instance, which means if you then try and save on another site, it won't find the existing file to sync too. basically the id has to be 'reconstructable' at either end so can only be something that we know will be set on either end.
I will have a look at what we can do - thinking about it (as i type) i wonder if moving to a level based thing for content might work ?
the reason there is a tree at all is so we ensure the root nodes are there before the childnodes are imported, but if we just put each node in a folder based on its level ( so have Conent/1/2/3/4/nodename.config) - then we might get loads of levels and the existing code might work because it just walks down the folder structure.
that might work, so i will have play and see what works well and if there are any issues with any of the ideas .
How about storing a separate Xml-based file in the root that maps "arbitrary" numbers to node names/hashes. That way you could control the directory names as either hashes or node names; add another setting to allow them to stored "flat" or in a "tree" with the caveat that you can only go x levels deep in the content... the Xml would give you a way to reconcile things, instead of traversing the directories, you would traverse the Xml.
I'd be ok if that mode were only available when using manual for syncing and saving...
Hi,
i thought about (and started down the road of) the arbitrary root hashes, as was looking at a guid/level folder things - but then realised the order becomes important (as we don't want things importing first just because their guid starts with a 1)
so i have put together a change that uses the level folder - https://github.com/KevinJump/uSync/issues/130#issuecomment-296710595
this change will mean folders look like this.
combined with the shortID name setting I think it makes the content folder never go over 41 characters in length.
it needs a little testing, but this should hopefully help a lot with this issue.
That looks like a reasonable solution to me. :-)
is working on a reply...