Long File Path Report for NetWare

We have persistent problems in our NetWare infrastructure with illegally long File paths. Windows has a documented limit of , I believe, 216 characters for a UNC file path, although in practice various applications will function to a greater or lesser extent with longer paths up to around 230/240 characters. It seems to be variable between different applications, even different members of the Office suite. It appears to be possible for Office applications to create and save documents that they cannot subsequently open!

More importantly though when users drag and drop folder structures whilst managing data it is extremely easy for them to create very long file paths, vastly exceeding Windows’ ability to handle and even exceeding the length that some server utilities, backup software for instance, can handle. Thus one can end up with data that cannot be read, copied, deleted or even backed up unless the paths are modified. This is a very undesirable state of affairs,so I created this utility to report on such paths and advise the users on what action to take.

This tool makes use of trustee.nlm, which will report ownership of files and folders. Trustee seems to fail with paths something over 300 characters long, so may not report every affected document but its unlikely to encounter a folder structure in which all documents are beyond its ability to report, and one may hope that the remedial measures taken for those folder structures it can report on will in turn bring any even longer ones within its scope.

The utility runs in two stages. Firstly one must run trustee with the /et /eo switches which causes it to list the path and owner of every document that it is capable of successfully reading, and when that has completed then the tparser.php script must be run to parse the output and produce the reports. The utility can produce the output in two formats – an html file containing a list of all illegal file paths, sorted by owner and, given the availability of an LDAP directory containing user names and email addresses, individual warning emails to each user. The parser also uses a “mapping file” which enables you to convert the absolute Netware syntax paths in the trustee output to drive letter paths that will be understood by the users. This is explained further in the source code, and is probably the most finicky part of the setup..

Trustee must of course be run on the server, and a Cron job out of normal working hours is preferable. The PHP script is probably best run on the server too, but given a workstation with access to the files it can be run on any php platform. In development and whilst introducing the system I found it convenient to run it directly from the Eclipse platform on my workstation.

You will probably want to spend some time customising the email message to the users, which is held in the script rather than a separate file. It might well be good to include a link to an FAQ page held on your intranet: this process seems to be an effective generator of support calls seeking clarification. Depending on how your Network is run you may find that file ownership creates anomalies. There is no way of identifying paths where the owner has changed job and is no longer responsible for the data. Your Network administrators may also find themselves with very large lists of files. If they have been in the habit of migrating data between servers without preserving file ownership then they will “own” vast chunks of data, especially older data, themselves.

The download includes example trustee output and mappings files. Its based on real data, but with the text scrambled of course. The example should work with the example files stored in the script directory. You’ll need to use your own data and LDAP server to test the email feature. Click here for an example of the html output.

OES

OES lacks the trustee.nlm utility. There is the metamig utility which has some of the same functionality, but will not list file ownership and exports only in XML format. I have an enhancement request in the system with Novell, so we shall see if that is fulfilled before my need is so great that I give up and attempt to write a new version that does the file system export itself.

Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.