With NSM3 the migration didn't handle those, had to track the errors and
fix manually. Same with few special characters that stopped migrations..

Don't know if NSM4 has improvements on that..

-sk

On 13.3.2015 21:36, kjhurni wrote:
>
> Out of curiosity:
>
> We have found that due to different OS (client and server) and various
> programs (Thank you MS And your lovely APIs), that we have users who
> have created:
> a) file paths
> and/or
> b) file names
> and/or
> c) both
>
> Where the limits are "too long" so you cannot rename the file or delete
> it (via Windows Explorer).
>
> Since we're on OES Linux, we have (in the past) used either NRM or Linux
> CLI to rename/move/delete those items.
>
> Does the Storage Manager (current shipping version) with cross empire
> migration "deal" with these when moving to Windows?
> (ie, can there be any logic coded to like shorten things?)
>
> Thank you
>
>

Kevin,
we've had all kinds of issues with "long folder file names"on OES Linux using NSS. I can't figure it out, because if I do the math, this particular share filename is only 172 characters.. but users cant open/rename/delete. I have to ssh into the server and rename it to something shorter, then its able to be manipulated. Whats the limit?!?!? happens on both XP and windows 7 using latest clients. OES is fully patched too. I'd like to be able to tell users "You cant have folder file names over X characters" but according to documentation, its 255. I fired up Procmon when trying to open the document and it shows \\servername\path\folders\filename then PATH NOT FOUND.

joebrug;2391762 wrote:
Kevin,
we've had all kinds of issues with "long folder file names"on OES Linux using NSS. I can't figure it out, because if I do the math, this particular share filename is only 172 characters.. but users cant open/rename/delete. I have to ssh into the server and rename it to something shorter, then its able to be manipulated. Whats the limit?!?!? happens on both XP and windows 7 using latest clients. OES is fully patched too. I'd like to be able to tell users "You cant have folder file names over X characters" but according to documentation, its 255. I fired up Procmon when trying to open the document and it shows \\servername\path\folders\filename then PATH NOT FOUND.

The limit isn't really 255. There's an MS KB article which lists the various answers. Basically:
It depends on the Client OS
It depends on the Server OS
It depends on which one of the 3 or more API's that were used to write/call/access/whatever the data
AND:
Windows takes the COMPLETE path and filename into account.
so F:\blah
MAY be:
\\serverwithlongname\reallylongsharename\blah
So you may think it's:
F:\blah = 7 characters
when it's really the 2nd example

We've had times where even renaming the file doesn't fix it because the PATH is too long.

If I knew scripting well enough I could possibly shrink stuff down, but then of course, we run into a logistical issue of breaking things as well. Just sounds like a new-win situation.

But it would be "cool" if the NSM could execute some Linux script to "fix" things. But not sure how (maybe parse the characters, etc.)?

Sorry, found your thread via a search, so not quite related to NSM at all :) .. im on chat with novell support now. its looking like if the filename is 127 characters, it works.. but once you try 128 characters, you get path not found stuff, etc. I'm testing things now. either way, I should be way under 255 even if adding the "long" paths.

joebrug;2391788 wrote:
Sorry, found your thread via a search, so not quite related to NSM at all :) .. im on chat with novell support now. its looking like if the filename is 127 characters, it works.. but once you try 128 characters, you get path not found stuff, etc. I'm testing things now. either way, I should be way under 255 even if adding the "long" paths.

I *think* (we had to use some other tool whilst evaluating code) that we found the limit to be like 207 characters. But that's because the destination path is so long in our case (the new \\server\share is much longer than the source server). This is on OES2 SP3 linux, BTW, on NSS volumes.

Ah.. well turns out that I stumbled upon a bug that showed itself after applying the March patches for Oes11.

https://www.novell.com/support/kb/doc.php?id=7016443

Novell provided me with the patch on server side.. applied it, restarted ndsd, was able to manipulate the files again :)

joebrug;2391792 wrote:
Ah.. well turns out that I stumbled upon a bug that showed itself after applying the March patches for Oes11.

https://www.novell.com/support/kb/doc.php?id=7016443

Novell provided me with the patch on server side.. applied it, restarted ndsd, was able to manipulate the files again :)

Good grief! Well for better or worse, we're still on OES2 SP3, so that's probably why we didn't get bit by it. But still, very frustrating that something like that (that's very obvious) slipped through testing and you have to wait a month (well in your case you got the patch early).

Thanks for the feedback.

joebrug;2391792 wrote:
Ah.. well turns out that I stumbled upon a bug that showed itself after applying the March patches for Oes11.

https://www.novell.com/support/kb/doc.php?id=7016443

Novell provided me with the patch on server side.. applied it, restarted ndsd, was able to manipulate the files again :)

Good grief! Well for better or worse, we're still on OES2 SP3, so that's probably why we didn't get bit by it. But still, very frustrating that something like that (that's very obvious) slipped through testing and you have to wait a month (well in your case you got the patch early).

Thanks for the feedback.