Main Forum Index

Forum Home

Post Reply

Email Forum Admins

Log In

Search Forums

Read Messages

Send a Message

Edit Your Settings

Forum Rules


Always shocked at how lazy MS programmers are with regards to Mac apps......
By:  P. Briscoe (Non running-dog anti-imperial anti-Bush unapologist name-changer; 23534)
Posted on: 11-05-2019 20:38.
Client: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36
IP: Logged 
Message views: 30 (Score: 0)  

My solution was to put a little script into JAMF that users can run from Self Service to recursively nuke all "illegal" characters in their OneDrive folder to stop the endless errors that occur when people need to start synching legacy datasets--the kind that are chock full of illegal characters and leading spaces in file/folder names. And it's not the user's fault that one Filesystem allows a character and another doesn't. It's up to software devs and/or IT admis to fix that for them.

I just used zsh's "zmv" command, which is quite powerful (and dangerous if you're not careful). Took me (a non-coder) about 2 hours to craft and test a solution, so there's no excuse for why OneDrive sync client can't offer to fix user filenames for their customers.

But that doesn't solve another known issue: total file path length.

OneDrive imposes a 260 character MAXPATH. Mac filesystems and apps like Finder have MAXPATH as well, but it's much, much higher.

So deeply nested folders with long folder and file names are fine on a Mac until you try to sync them with OneDrive. Then you're in for a world of pain.

Hard to script a solution for that issue. I have no problem stripping out slashes and replacing them with underscores, but we can't break user-defined organization hierarchies.

Edited by P. Briscoe at 11/5/2019 8:44:15 PM

Edited by P. Briscoe at 11/5/2019 8:47:49 PM