I have just installed usync 2.5 and usynContent 0.7.2 on a umb7.1.8 install.
disabled import, enabled export.
when it first runs and creates files under usync, the entire process fails if it hits a pathTooLong exception.
I am not, yet, sure on how to limit editors to key-in reasonable page names.
Is it possible to give error bubble (i.e. publish validate failed because of this.. sort of notice to user) onSave event if the page name is too long (in 7.1.8 of umbraco)? This is off-topic but asking here in the hope that you may know a method as you have extensive knowledge on Events.
Meanwhile, is it possible to allow uSyncContent to continue if it hits the pathTooLong exception? Because of few nodes scattered here and there, i cant run the initial export;
2015-11-07 12:42:07,709 [386] ERROR Umbraco.Core.UmbracoApplicationBase - [Thread 452] An unhandled exception occurred
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
yes i have seen the long path name thing before, thats why doctypes and templates write out a def.config file not name.config in an effort to keep names short - it works a bit but not completely. and i think with content it becomes an even bigger problem :-(
Unfortunately the name lenght thing is a bit of a .net pain. it's inside the core of the .net libraries that they hit MAX_Path and throw a wobbler, to work around this you apparently have to step outside of the .net libraries and start to use the raw Win32 API calls :(
I have considered putting an option in there where the filenames and folders are named after internal IDs - this would solve a lot of problems (like the name length one), but it would make the directories pretty meaningless if you were actually trying to look for something.
I am not sure everyone does look in the folders, so an option to write out Ids not names might be the "simple" way to fix it - it would mean quite a bit of code digging to make sure i capture every file write, but at the moment that's the best idea i've had - happy if anyone has another one :)
I have been reading the forum of both usync and usync content to understand about the inner working and very impressed with how you designed in modular principle (core, content ..).
Before I discovered the turnoff errors, in an attempt to get something working to test the functionality, I have tried various sites, small to medium to large.
In every single one of them I hit the path too long, one way or the other. If its not content, then its media, media upload field in doctype etc.
Like you said it hits the .NET and Win32 API call wouldnt do justice.
I did write save handlers to shorten names, iterate all nodes and trim etc. in between discovering the turnoff errors feature. But in each attempt I knew this was not the way to go.
I would vote for the Ids, guids would be overkill, readability is nice but the seamless/painless sync ranks higher.
From developer/integrator perspective, If ID was used I could get it run in all of the tested enviroments, and get up-n-running and synching.
I noticed that this option has now been removed - is there something else to get around this? I checked out a version of code which has snapshots that are causing this error. I don't have a uSyncConfig file so can't find where to set the option to stop throwing errors.
Can we configure usync to go to an absolute path instead of relative?
This would help. cause right now, our url is very long in itself.
and the physical path to the site (in dev)
C:/inetpub/(folder)/(maindomain)/(subdomain)/
so its actually pretty long.
the ids are actually still very long.
the only other way is to save them using the array index 0/0/1/content.config.
just thinking out loud here
Allow to continue if hit by path too long exception
I have just installed usync 2.5 and usynContent 0.7.2 on a umb7.1.8 install.
disabled import, enabled export.
when it first runs and creates files under usync, the entire process fails if it hits a pathTooLong exception. I am not, yet, sure on how to limit editors to key-in reasonable page names. Is it possible to give error bubble (i.e. publish validate failed because of this.. sort of notice to user) onSave event if the page name is too long (in 7.1.8 of umbraco)? This is off-topic but asking here in the hope that you may know a method as you have extensive knowledge on Events.
Meanwhile, is it possible to allow uSyncContent to continue if it hits the pathTooLong exception? Because of few nodes scattered here and there, i cant run the initial export;
I just noticed there is an attribute to not halt on errors, including here for others who might hit the same issue;
In /config/usyncSettings.config there is an attribute dontThrowErrors with a nice description;
I have installed usync in few different environments and the path too long issue is being hit in numerous scenarios;
1) content page was too long
2) media name was too long
3) upload attribute inside a document type, where the image is uploaded, the file name was too long.
Not sure about your plans on how to handle the too long path issue, from what I gathered this issue is encountered in numerous scenarios.
Would be interested to hear your thoughts and plans on this.
(For reference I am stuck pre 7.3, for number of reasons, and hoping to get this to work).
Hi
yes i have seen the long path name thing before, thats why doctypes and templates write out a def.config file not name.config in an effort to keep names short - it works a bit but not completely. and i think with content it becomes an even bigger problem :-(
Unfortunately the name lenght thing is a bit of a .net pain. it's inside the core of the .net libraries that they hit MAX_Path and throw a wobbler, to work around this you apparently have to step outside of the .net libraries and start to use the raw Win32 API calls :(
I have considered putting an option in there where the filenames and folders are named after internal IDs - this would solve a lot of problems (like the name length one), but it would make the directories pretty meaningless if you were actually trying to look for something.
I am not sure everyone does look in the folders, so an option to write out Ids not names might be the "simple" way to fix it - it would mean quite a bit of code digging to make sure i capture every file write, but at the moment that's the best idea i've had - happy if anyone has another one :)
Hi Kevin
I have been reading the forum of both usync and usync content to understand about the inner working and very impressed with how you designed in modular principle (core, content ..).
Before I discovered the turnoff errors, in an attempt to get something working to test the functionality, I have tried various sites, small to medium to large.
In every single one of them I hit the path too long, one way or the other. If its not content, then its media, media upload field in doctype etc.
Like you said it hits the .NET and Win32 API call wouldnt do justice.
I did write save handlers to shorten names, iterate all nodes and trim etc. in between discovering the turnoff errors feature. But in each attempt I knew this was not the way to go.
I would vote for the Ids, guids would be overkill, readability is nice but the seamless/painless sync ranks higher. From developer/integrator perspective, If ID was used I could get it run in all of the tested enviroments, and get up-n-running and synching.
thanks again for sharing this, very inspiring.
Hi Kevin,
Did the id pathname setting ever get released? The content edition is great, but I hit the character limit in just about every install.
Hi Liam
no, it got missed from the v3 build :(
but now it's going to be in the next release :)
https://github.com/KevinJump/uSync/issues/85
I noticed that this option has now been removed - is there something else to get around this? I checked out a version of code which has snapshots that are causing this error. I don't have a uSyncConfig file so can't find where to set the option to stop throwing errors.
Hi
uSync should create a config if one is missing, but it that isn't helping
you can take a copy of the configs from the source
https://github.com/KevinJump/uSync/blob/Dev-v7_4/Jumoo.uSync.BackOffice/Config/uSyncBackOffice.Config
and
https://github.com/KevinJump/uSync/blob/Dev-v7_4/Jumoo.uSync.Core/Config/uSyncCore.Config
The back office config, has the don't throw error setting and use short path names settings.
Hi Kevin,
Getting the issue with Usync snapshots, have tried adding the id option to the config but it makes no difference here.
Does snapshots need updating to support this option?
Can we configure usync to go to an absolute path instead of relative? This would help. cause right now, our url is very long in itself. and the physical path to the site (in dev)
C:/inetpub/(folder)/(maindomain)/(subdomain)/
so its actually pretty long.
the ids are actually still very long. the only other way is to save them using the array index 0/0/1/content.config. just thinking out loud here
is working on a reply...