> 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?
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