Handle CMIS paths longer than the filesystem path limit

[antton]

I have just noticed that when I try to sync with alfresco, the aplication crashes just when it finds a long folder+filenames for example:

C:\Users\ulhi\CmisSync\Ikasketa_burutza\2012-13_ikasturtea\Fabrikazio_mekanikoa\PPFM\Kudeaketa\Plangintzak_jarraipenak\Alor_bilerak\Txostenak\FOL\ANEXO II PERDIDA DERECHO EVALUACION CONTINUA\Anexo II - INFORME SANCIONADOR PARA EL ALUMNO 2012 XXXXXXXXXX YYYYYYYYYYYYYY ZZZZZZZZZZZZZZ.doc

I just rename the filename and cmissync starts working like a charm!

[nicolas-raoul]

Thanks for the feedback! So that's 287 characters. Maybe some limit in the database... I will try now!

[nicolas-raoul]

Windows prevents me from creating paths longer than 260... it says for instance "The file name(s) would be too long for the destination folder", or just prevents me from typing. How do you create such files?

[tgeens]

That is a limit in the win32/.net api. MAX_PATH=255, you can find that in the msdn documentation.

You can have deeper paths in the Windows explorer (using UNC path), but that doesn't work with MS Office. (The limit for excel is even a few characters less.

[antton]

Hi again,

I created the file via web and all the directory structure as well, soo if you open your Document management system you could create wherever you want and then try to sync from the root folder.

;)

[nicolas-raoul]

So if I understand well, the steps are as below:

1. On Alfresco, create a file with path length>255
2. Sync with CmisSync
3. CmisSync tries to create the file on Windows, but it fails because of the win32 limit That's it?

At a minimum, CmisSync should avoid crashing. What is the best solution in such case?

• Shorten the file's name?
• Skip the file?
• Create a sort of "folder's carriage return", a special folder from which the path can continue?
• Something else? Your ideas are very welcome :-)

[tgeens]

As a workaround you could try to remount the sync-folders as a virtual drive somehow, that saves "Users\ulhi\CmisSync\Ikasketa_burutza".length characters :-)

[antton]

You understood properly.

And about the best solution...

Shorten the file's name? 
As long time ago in MSDOS filename~.ext, looks like very old solition and not really good.    

Skip the file?
Would be great but if you need the file tomorrow morning in a meeting and you think that is already sync and then you can't find? Skip with somethig else could be great!

Create a sort of "folder's carriage return", a special folder from which the path can continue?
I don't understand properly this idea..

Something else? Your ideas are very welcome :-)
Let me think about it with more people I've got a few alfresco experts near to me and maybe they could see any other good solution... even the community :+1:  

[antton]

I just leave here the link MSDN article http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath

I hope we could find a good solution ;) but for now I'll keep the files without exceded the limits manually.

[nicolas-raoul]

Anyone knows how Alfresco solves the problem when mounting a long-name hierarchy via WebDAV or CIFS?

[tgeens]

This has come up quite a few times on Alfresco JIRA. There were some smaller bugs in Alfresco, but they don't have a solution for the real problem.

https://issues.alfresco.com/jira/browse/ALF-743 https://issues.alfresco.com/jira/browse/ALF-673 https://issues.alfresco.com/jira/browse/ALF-682 https://issues.alfresco.com/jira/browse/ALF-16772 https://issues.alfresco.com/jira/browse/ALF-15755

It's not a direct issue with Alfresco, it's an issue with the win32 api. Ubuntu Desktop is happy with long paths on an alfresco-webdav mount.

[nicolas-raoul]

http://stackoverflow.com/questions/14952268/c-sharp-io-library-that-supports-long-paths-to-solve-pathtoolongexception

[antton]

Hi,

I was looking your stackoverflow discussion, and I also found this library to fix the same problem: http://gallery.technet.microsoft.com/DelimonWin32IO-Library-V40-7ff6b16c

But I was thinking that if we use any of them, then the windows explorer is not gonna be able to read the folders, as I see Delimon created their own Windows Explorer... soo I'm not really sure if we would fix anything in that way.

Anyway I think that you are making a fantastic work and investigation soo keep on that soo well as now!

[ymolinet]

In my point of view, we could use SymLink (http://msdn.microsoft.com/en-us/library/aa363878%28v=vs.85%29.aspx) to download file when path length is >= 260 car. But it result a bad user experience to access it localy. We can not evaluate Delimon integration with other software as Office to access this file. Perhaps, we could inform user and create SymLink in CmisSync directory. it's a complex enhancement.

First way, we could not download this and log information in debug file.

[ymolinet]

SymLink feature could also fix this usage : https://groups.google.com/forum/?fromgroups=#!topic/cmissync/1tAhfA7nI0M

[b333z]

.Net MIT licensed library for long path support: http://alphafs.codeplex.com/

[tgeens]

With alphafs you would be able to do file operations on long-file-paths from .NET, but that doesn't make MS Office work with the long paths :-)

Than again, that is not your issue to solve. I'm just pointing out that putting effort into porting your code to use this alphafs lib doesn't make the problem go away for the end-user.

[nicolas-raoul]

Shortening names could be a solution, and can be implemented cleanly since CmisSync already uses a mapping to cope with systems that don't understand UNICODE.

If you open the .cmissync database file, you can see two columns for each file: remotePath, path. For instance, remotePath=Sites/ぱ, path=Sites/は゜ on Mac because Mac does not understand ぱ and splits it into two characters は゜. CmisSync already does this, so it could also do:

remotePath="Sites/veryveryveryveryveryveryveryveryveryveryveryverylong/folder", path="Sites/veryve~1/folder" There will probably some edge cases that need to be taken care of, but that seems doable. Any objection, or insight about this idea?

[nicolas-raoul]

At least we shoud let the user know when this problem happens.

[phew01]

Hi,

Stumbled on this thread because I noticed an already synced directory tree (cmissync'ed alfresco) went into an endless loop. Looking in the log file, it seems that cmissync is continuously trying to sync the offending docs (with path > 260 length). Is there any solution to this?

Every sync run seems to retry the formerly failed transfers.

Apart from the log I don't see any warning / report that some docs have not been sync'ed.

[Bennopia]

I found a solution to this issue. Share the folder that you wish to sync to or use the Administrative shares, and use the UNC path in place of the file path. The character limitation for UNC paths is in the order of 32,000 characters, not 260 per file paths. An example of using the administrative share is: when CMISSYNC displays local save path as "C:..." replace "C:" with "\localhost\C$" or "\127.0.0.1\C$". Administrative shares are by default only available to local administrators, but most users can create local shares. Use a similar approach for the local file share if you don't have local administrator permissions or administrative shares are disabled. Using the UNC path approach removes the limitation without need to muck around changing file names, or making them less descriptive (e.g. stripping out version numbers, reviewer initials, etc, just to meet a file character length limitation - can be upsetting for those who create and use these documents on a daily basis).

[tgeens]

@Bennopia Too bad MS Office doesn't support UNC paths ?

[antton]

Are you sure? https://support.microsoft.com/en-us/kb/918773

[Bennopia]

You can use the NET USE command (with persistent flag) to connect to a share deep enough within the UNC path to prevent the issue or use the SUBST command if no shares are being used.

e.g. SUBST F: C:\Users\ABCUser\CMISSync\ProjectA

Cheers.

[Bennopia]

The request was with reference to CmisSync, not Word. I tested it on CmisSync before publishing as I was having same issue. CmisSync supports UNC paths (is working here!).

For Word, Lotus Notes, etc, use SUBST, NET USE or even a combination of the two. I’ve deployed using these within large corporate environments with no issue.

[nicolas-raoul]

Hi all, Could you please try this new CmisSync version, and let us know whether it handles long paths correctly? I just tested it a very little bit and it seems to work, but your testing and feedback is needed. Please note that you must also enable long paths as described at https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ Looking forward to your feedback!