any way to enable long file names

you can rename them.

this is generally a client issue, ie windows wants a path less than 250ish characters

we dont want to rename them. thats the point.

well, its not a nas problem, so there is not any 'patch' or solution other than to rename them ( or possibly put them in a short named share).

Maximum Path Length Limitation In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections. The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path". Note The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length. The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters. There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions. When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12). The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not be able to interpret properly.

http://msdn.microsoft.com/en-us/library ... 47(v=vs.85).aspx

Note that it is the full path name length that provokes this problem. When copying files to the NAS it will only occur when the full path name on the NAS is longer than the corresponding path name on the PC (and even then only when the longer name exceeds the 260 char limit).

If the users always map the NAS share to a drive letter (and always use the mapped drive) they should not see this problem.

Although (of course) if they attempt to move these long directory trees into a new subfolder (making the folder structure deeper still), they will see it - whether they are doing this on a local drive or on the NAS. So at some point they are likely to need to flatten their folder structure (or shorten the names) to avoid this anyway.

dirkdigs wrote:
i was moving a bunch of data (CIFS) acrss the network to the NAS but I got a few errors relating to file names being too long. is there any patch or anything that resolves this issue? thanks.

What type of client are the files coming from (Windows, Mac, Linux, etc.)? As noted above, there is a limitation within CIFS as to the file name size, as well as types of characters. If the client device supports a different network protocol (such as NFS for linux, AFP for Mac, etc.) then try using something other than CIFS. NFS and AFP do not have the same limitations.

http://www.readynas.com/forum/viewtopic.php?f=23&t=31697&p=174110#p174110

dbott67 wrote:
... If the client device supports a different network protocol (such as NFS for linux, AFP for Mac, etc.) then try using something other than CIFS. NFS and AFP do not have the same limitations.

True enough, NFS and AFP allow longer paths.

Though this MAX_PATH issue for Windows goes well beyond CIFS - almost all Windows applications have file names dimensioned to [MAX_PATH] - it is not just the network file protocol. So for Windows users it is best if they bite the bullet and flatten the folder structure (or map the drive). Otherwise, they will just run into more problems after they get the data copied.

StephenB wrote:

True enough, NFS and AFP allow longer paths. Though this MAX_PATH issue for Windows goes well beyond CIFS - almost all Windows applications have file names dimensioned to [MAX_PATH] - it is not just the network file protocol. So for Windows users it is best if they bite the bullet and flatten the folder structure (or map the drive). Otherwise, they will just run into more problems after they get the data copied.

I agree, however, the OP did not specify that they were using a Windows PC (only CIFS). I didn't want to make the assumption. I did that a few weeks ago when someone posted that their new NAS wouldn't boot up when they installed the hard drive. Of course, they left out the fact that it was a previously used drive with all of the their data. It didn't turn out well:

http://www.readynas.com/forum/viewtopic.php?f=20&t=57411&p=323994#p323987

:oops:

Yes... I agree that if the source isn't windows then NFS or AFP would be better. MAX_PATH is not the only issue, there is also the characters allowed in file names and case sensitivity.

its a windows box. so NFS or AFP are not options.

it do however get more luck when i map to a drive letter and then copy over.

The problem is with regards to the total path length. I've had this same problem. I was unable to delete the files through smb/rsync/http (DAV).

The solution I found was to create a drive map as deep as possible to the offending files. I mapped \\readynaspro4\some\ridiculously\long\path\to\the\root\of\the\directory\where\i\was\having\the\problem to y:. From there the path length to the files is only 200 or so characters and the files were then deleteable :) huzah!

I've no idea why this is a problem. ext2/3/4 can deal with much longer paths. Haven't bothered to investigate further.