That might be the case.
In any case synchronization logic has no limitation whatsoever and all
such limitations would be directly derived from the OS file system
constraint.
Perhaps working with shorter paths would be an acceptable (and may be
the only) workaround?
Nandini
On Sep 18, 2009, at 7:43 AM, glassfish_at_javadesktop.org wrote:
> I used to do more work on Windows than I do any more, so I might not
> be remembering correctly. And I am certainly not an expert on the
> GlassFish synchronization logic so maybe this has no bearing on the
> problem. But here goes anyway.
>
> GlassFish might be able to create a file in this case using
> something like
>
> File f = new File(parentDir, file);
>
> in which neither the directory nor the relative file path provided
> exceeds the max file length by themselves -- only together do they
> lead to too long a path.
>
> But perhaps the code which tries to delete the file uses some other
> technique for creating the File object that constructs the full path
> which, to Windows, is then too long.
>
> Just a thought.
>
> - Tim
> [Message sent by forum member 'tjquinn' (timothy.quinn_at_sun.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=364624
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>