Thatıs not really an acceptable work around in our case.
Iıll go ahead and file a bug I guess.
On 9/18/09 3:08 PM, "Nandini Ektare" <Nandini.Ektare_at_Sun.COM> wrote:
> 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
>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
--
Sean Comerford, Software Engineer
ESPN.com Site Architecture Group
Office: 860.766.6454 Cell: 860.329.5842