On Fri, Apr 25, 2008 at 01:52:05PM -0400, Greg Freemyer wrote:
> On Fri, Apr 25, 2008 at 10:55 AM, Karolin Seeger wrote:
> > Hash: SHA1
> >
> > Release Announcements
> > =====================
> >
> > This is the third preview release of Samba 3.2.0. This is *not*
> > intended for production environments and is designed for testing
> > purposes only. Please report any defects via the Samba bug reporting
> > system at https://bugzilla.samba.org/.
> >

> > Major enhancements in Samba 3.2.0 include:
> >
> > File Serving:
> > o Use of IDL generated parsing layer for several DCE/RPC
> > interfaces.
> > o Removal of the 1024 byte limit on pathnames and 256 byte limit on
> > filename components to honor the MAX_PATH setting from the host OS.

> Can someone explain that some more. Is that a tightening or loosing
> of the restriction?

This is a losening of the restriction. Incoming paths from clients
can now be as long as the PATH_MAX of the system hosting Samba.

> Or point me do a discussion about how it was decided to do this?

Look back in Samba-technical for the comments from Volker and
myself on restructuring to smb_request and removal of pstrings.

> === My concern
> IIRC MAX_PATH is 512 under Windows, but it is a lie that cannot be
> trusted. It is just the limit for the old API. The new Unicode APIs
> do not honor that define. I'm concerned this may be true of other
> filesystems / OSes.
> In particular with Robocopy that comes with Windows 2003 Resource Kit
> you can work with pathnames up to 32K I believe it is. (See the
> Robocopy release notes for details). A lot of tools are still
> restricted to 512 chars, but I am fairly confident that 512 is no
> longer a fundamental limitation with newer Windows products.

We should now be able to work with any Windows pathname a client
generates, no more 1024 byte restriction.