function [sctAttribs, sNormPath, sNearest] = li_fattribs(sFilePath, bFollow)
Checks character row vector <sFilePath> to be the path of an existing file or directory and, in case, tries to retrieve this fs-objects attributes.
If <bFollow> is omitted or false, symbolic links are not resolved and all flags are set according to the symbolic link object itself. Otherwise the flags are retrieved from the linked file object in case it could be found, but still from the linked file, if not. So in the latter case isSymLink (see below) would still be returned as true.
<sFilePath> should be an absolute path, otherwise its identification relies on the current os's relative path handling conventions, but usually this is matlabs current directory. With MS Windows OSs a root path with no drive (e.g. starting on '/' or '\') is not considered absolute and is resolved using the current directory's drive.
If 2nd output <sNormPath> is present and no true <bFollow> was passed, it will contain a lexically normalised path, but no symbolic links or file system aliases will be resolved. Normalisation rules depend on the os. If 2nd output sNormPath is present and <bFollow> is passed as true, <sNormPath> will contain a lexically normalised path with all symbolic links and file system aliases resolved. Normalisation rules, again, depend on the os. If resolving of symbolic links fails (e.g. if the target does not exist), there might still be the unresolved, but normalised, path be returned, along with the respective attributes. In both cases a normalised path will be returned, even if the file does not exist, to support the use with file or directory creation. Neither returned path will be checked for file object naming restrictions as far as they do not interfere with lexical path restrictions. Thus a non-existing path might be returned containing characters disallowed by the os itself or by the filesystem / filesystem-driver the path points to (if any).
If 3rd output <sNearest> is present, it contains the nearest existing ancestor directory of <sNormPath>, if <sNormPath> does not exist, and <sNormPath> itself otherwise. If no existing ancestor directory could be determined, an empty path is returned.
Where the file management of file system and os allows to completely hide an existing file from a user, an actually existing file might appear as non-existent for obvious reasons. This is not to be confused with the hidden flag, that doesn't prevent any actual access.
Some operating systems manage special files that represent devices, sockets and others. Here the 'exists' flag can be true, while 'isDir', 'isFile' and 'isSymLink' are all false.
<sctAttribs> is a struct with the following, all logical, members: 'exists': True if an fs-object was found existing on <sFilePath>, otherwise false along with all other struct members apart from 'isAbsolute' and 'isNameOnly'. 'isAbsolute': True if <sFilePath> is an absolute path. 'isNameOnly': True if <sFilePath> consists of a file object name only (no root or parent directory given). 'isDir': True if fs-object found is a regular directory. 'isFile': True if fs-object found is a regular file. 'isSymLink': True if fs-object found is a symbolic link to another fs-object. 'isReadOnly': True if fs-object found has a read-only flag set (windows systems only). This flag itself is only indicative and doesn't prevent actual modifying or deleting of the fs-object. 'isHidden': True if fs-object found has a hidden flag set (windows systems) or on unix systems starts with a dot ('.') or ends on a swung dash ('~'). 'userCanRead': True if the currently active OS-user has reading access to the fs-object. In case of a directory this usually means the user might retrieve a list of files and directories that are its children. 'userCanWrite': True if the currently active OS-user has writing access to the fs-object. In case of a directory this usually means the user might add fs-objects to it and might delete child fs-objects where the child objects access restrictions do not forbid it.