users@glassfish.java.net

Re: Long paths on windows

From: Nandini Ektare <Nandini.Ektare_at_Sun.COM>
Date: Thu, 17 Sep 2009 09:30:45 -0700

For some reason users_at_glassfish list had unsubscribed me...so
subscribed again and am resending the message....


On Sep 17, 2009, at 9:08 AM, Nandini Ektare wrote:

>
> On Sep 17, 2009, at 8:15 AM, Hong Zhang wrote:
>
>>
>>> No, we cannot manually delete the file. We have to copy to the
>>> root dir of the drive and then delete.
>>>
>>> We do not see this issue when deploying locally (or to the DAS)
>>> but that may just be due to the fact deploying to a remote node
>>> agent results (at least in our case / naming conventions) a much
>>> longer file path for that node agent.
>>>
>>> So the issue is why is it that Glassfish can able to *CREATE *the
>>> file but then cannot delete and whether there’s a work around
>>> (outside of getting a real OS or mapping a drive :-)?
>> I am not too familiar with the synchronization part of the logic of
>> node agent, maybe people who are more familiar with that part of
>> the logic can comment. Nandini?
>
> No, there are no limitations on file name sizes in synchronization.
> If the directory has all correct permissions, I would expect
> creation and deletion to work.
>
> Since this is a windows platform, one thing that I can think of at
> this point is that file may be *in use*. Is there any concurrent use
> of the file externally/internally(in deployment)?
>
> Thanks,
> Nandini
>
>>
>> Thanks,
>>
>> - Hong
>>
>>
>>> On 9/15/09 9:51 AM, "Hong Zhang" <Hong.Zhang_at_Sun.COM> wrote:
>>>
>>> Hi, Sean
>>>
>>> Re: Long paths on windows We’re using JDK 1.6 b 11.
>>>
>>> There aren’t any specific errors messages in the logs – just a
>>> generic “a domain operation could not be completed” stuff.
>>>
>>> The files in question are applications resources (created by
>>> Glassfish at deploy time) that are failed to be deleted during
>>> synchronization of a node agent with the DAS for an app
>>> un-deploy + re-deploy.
>>>
>>> As a result, previous versions are being left behind when we
>>> try to upgrade the version.
>>>
>>> This *ONLY* seems to happen when the file path in question is
>>> longer than the 255 size. Here’s an example of a file path
>>> that fails to delete:
>>>
>>> e:\apps\glassfish\nodeagents\espngamesql10\espngamesql10-
>>> gALLprAlertsGf\applications\j2ee-apps\alerts-central-app\alerts-
>>> central-subscribe-resp-ejb_jar\META-INF\maven\com.espn.alerts
>>> \alerts-central-subscribe-resp-ejb\pom.properties
>>>
>>>
>>> Looking at the path, there is no single component of the path
>>> (between the two '\') exceeding 255 so this should not be a
>>> problem.
>>>
>>> If you manually delete the path
>>> del
>>> e:\apps\glassfish\nodeagents\espngamesql10\espngamesql10-
>>> gALLprAlertsGf\applications\j2ee-apps\alerts-central-app\alerts-
>>> central-subscribe-resp-ejb_jar\META-INF\maven\com.espn.alerts
>>> \alerts-central-subscribe-resp-ejb\pom.properties
>>>
>>> would it work?
>>>
>>> Also could you try to deploy and undeploy the application just on
>>> DAS (deploy the application with the default target "server") to
>>> see if this problem is specific to the cluster
>>> scenario/synchronization?
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>> Our operations team is familiar with the issues around windoze
>>> and 255+ character paths but the weird thing here is Glassfish
>>> obviously was able to CREATE that file but can’t seem to
>>> delete it. And our understanding is that Win limitation is
>>> only applicable for certain tools like file explorer, etc (see
>>> _http://support.microsoft.com/kb/177665)_.
>>>
>>> As much as I’d love to get us off windows, that’s not an
>>> option right now :-( So if there’s any sort of work around we
>>> can implement, more details on it would be great.
>>>
>>> On 9/14/09 8:10 PM, "Hong Zhang" <Hong.Zhang_at_Sun.COM> wrote:
>>>
>>>
>>> Hi, Sean
>>>
>>> Which JDK were you using?
>>>
>>> There was a JDK bug on this
>>> (http://bugs.sun.com/view_bug.do?bug_id=6182812) which got
>>> fixed in 1.6 and 1.5_06.
>>>
>>> There is still the windows restriction that a single
>>> component of the path can not exceed 255 characters. In
>>> your case, is the length of whole path exceeds 255
>>> characters or one component of the path exceeds 255
>>> characters?
>>>
>>> It will be useful if you could share the path information.
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>> Comerford, Sean wrote:
>>>
>>> Long paths on windows Is there a known issue with
>>> Glassfish managing long path names on Windows?
>>>
>>> We’re using Windoze 2k3 and while Glassfish *IS* able
>>> to deploy an application that results in a very long
>>> directory structure being created (i.e.
>>> c:\foo\bar\blah\... Where the path ends up being 255+
>>> characters), there are problems when you attempt to
>>> undeploy the app. It fails with “invalid file name” or
>>> some such nonsense.
>>>
>>> We’re using Glassfish 2.1 b60e.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sean Comerford, Software Engineer
>>> ESPN.com Site Architecture Group
>>> Office: 860.766.6454 Cell: 860.329.5842
>>
>