Tweet
I'll preface this by saying this was no person's fault at The Client or in my office. This was down to system design, which would fall on someone's shoulders at the developer's side, which is a big-name corporation, and it's easy to blame them for everything. Anyway...
Among the various responsibilities I have at my current IT position is assisting with some share drive reorganizations. This sort of thing happens all the time at The Client, as various departments are folded into others, or as new ones are created, and this sometimes means entire share drives need to be moved from one place to another.
"But wait, Jay," I hear you saying, "wouldn't that be a job better suited for the server admins, who can do all that stuff on the back end?"
And you would be correct. However, as the server admins have eighty bajillion other things to on any given day, they delegate all file moves under a certain file size to us.
Last month, [Office X] reached out to us, because they're going to be split off from/merged into/moved to another department this month and so they need their existing share drive moved over to their new location. I worked with my supervisor/coworker "SIL" to check the sizes of the folders we're going to be moving. At least three of the folders that I was in charge of checking would be too large for us, and so would go to the server admins (one folder alone was more than 1 TB in size), while the others would be our responsibility. We needed to confer with Office X to determine when to do the move, since a lot of these folders would be still be in use, and we can't move them if anyone is using the folders or their contents. We arrange it all to happen just before the long weekend.
Only, as I'm doing it-- and this takes up all my day, since 95% of my job deals with share drive stuff (mostly granting/removing access to folders etc), and I can't do the rest of it while the move is happening, or it slows down the move-- I start getting some error messages. All of them are basically that the file name will be "too long for the destination path." Which is a fancy way of saying "this folder is buried so deep under so many subfolders that it exceeds the buffer for the share path."
I can't force the move through, and we're not permitted to just pull an audible and push the folder through to some place else. That decision has to be made by Office X. Since I'm part-way through this move, and I don't know how many other folders will error up like this, I figure I'll compile a list of all folders that give this error, so we can pass the info off to Office X for their decision.
The problem I have, however, is the error message lists ONLY the last folder in the share path that gave the error. Which means I end up having to spend a few hours drilling down through folder after folder, trying to find the one whose name matches the one giving me the error. I COULD just give Office X the folder names from the error message, and leave them to figure it out, but my work ethic wouldn't let me leave it at that.
It was just a frustration that could have been more easily fixed if the developers had thought to make their error messages more clear for that kind of thing.
Among the various responsibilities I have at my current IT position is assisting with some share drive reorganizations. This sort of thing happens all the time at The Client, as various departments are folded into others, or as new ones are created, and this sometimes means entire share drives need to be moved from one place to another.
"But wait, Jay," I hear you saying, "wouldn't that be a job better suited for the server admins, who can do all that stuff on the back end?"
And you would be correct. However, as the server admins have eighty bajillion other things to on any given day, they delegate all file moves under a certain file size to us.
Last month, [Office X] reached out to us, because they're going to be split off from/merged into/moved to another department this month and so they need their existing share drive moved over to their new location. I worked with my supervisor/coworker "SIL" to check the sizes of the folders we're going to be moving. At least three of the folders that I was in charge of checking would be too large for us, and so would go to the server admins (one folder alone was more than 1 TB in size), while the others would be our responsibility. We needed to confer with Office X to determine when to do the move, since a lot of these folders would be still be in use, and we can't move them if anyone is using the folders or their contents. We arrange it all to happen just before the long weekend.
Only, as I'm doing it-- and this takes up all my day, since 95% of my job deals with share drive stuff (mostly granting/removing access to folders etc), and I can't do the rest of it while the move is happening, or it slows down the move-- I start getting some error messages. All of them are basically that the file name will be "too long for the destination path." Which is a fancy way of saying "this folder is buried so deep under so many subfolders that it exceeds the buffer for the share path."
I can't force the move through, and we're not permitted to just pull an audible and push the folder through to some place else. That decision has to be made by Office X. Since I'm part-way through this move, and I don't know how many other folders will error up like this, I figure I'll compile a list of all folders that give this error, so we can pass the info off to Office X for their decision.
The problem I have, however, is the error message lists ONLY the last folder in the share path that gave the error. Which means I end up having to spend a few hours drilling down through folder after folder, trying to find the one whose name matches the one giving me the error. I COULD just give Office X the folder names from the error message, and leave them to figure it out, but my work ethic wouldn't let me leave it at that.
It was just a frustration that could have been more easily fixed if the developers had thought to make their error messages more clear for that kind of thing.
Comment