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 :-)?
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\appli
>> cations\j2ee-apps\alerts-central-app\alerts-central-subscribe-resp-ejb_jar\ME
>> TA-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\applic
> ations\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