Skip to main content

Long paths on windows

9 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aliceten
Offline
Joined: 2013-12-03
Points: 0

You can use Long Path Tool for such issues, I will say, it works good.

Hong Zhang

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

From Sean's previous email, it worked with shorter file path, so it's
probably not related to file locking.

Anything special with remote agent as this seems to work fine locally?
The deployment code only creates the file locally on DAS and don't
create files on remote instances...

- Hong

>>
>>
>>> On 9/15/09 9:51 AM, "Hong Zhang" 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" 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
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Nandini Ektare

On Sep 17, 2009, at 11:12 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)?
>
> From Sean's previous email, it worked with shorter file path, so
> it's probably not related to file locking.
The previous mail also lists successful creation with longer sized
names. So it's most likely not a filename issue.
> Anything special with remote agent as this seems to work fine locally?
None. Quick check: Do you see this issue on other machines with agents
(as in are there other machines within the cluster other than the DAS
machine and the machine where failure occurs. And does the problem
occur on those as well)?
> The deployment code only creates the file locally on DAS and don't
> create files on remote instances...
There was an optimization added to retain old files and not delete
them on undeployment. Could it be possible that those files are still
in use? Perhaps their deletion fails because the app files are still
locked.
Can manual deletion be tried?

Nandini

> - Hong
>
>>>
>>>
>>>> On 9/15/09 9:51 AM, "Hong Zhang" 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" 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
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

[att1.html]

Comerford, Sean

Yes, it occurs on all the instances in the cluster.

There is no lock on the files ­ they are all being touched by the DAS
synchronization, un-deploy / deploy process

And, no, the file CANNOT be manually deleted via win explorer or the command
line. We have to copy the file to the root directory and delete from there.

Again, the question is why is Glassfish able to create but not DELETE these
files.

On 9/17/09 2:21 PM, "Nandini Ektare" wrote:

>
> On Sep 17, 2009, at 11:12 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)?
>>
>> From Sean's previous email, it worked with shorter file path, so it's
>> probably not related to file locking.
> The previous mail also lists successful creation with longer sized names. So
> it's most likely not a filename issue.
>> Anything special with remote agent as this seems to work fine locally?
> None. Quick check: Do you see this issue on other machines with agents (as in
> are there other machines within the cluster other than the DAS machine and the
> machine where failure occurs. And does the problem occur on those as well)?
>> The deployment code only creates the file locally on DAS and don't create
>> files on remote instances...
> There was an optimization added to retain old files and not delete them on
> undeployment. Could it be possible that those files are still in use? Perhaps
> their deletion fails because the app files are still locked.
> Can manual deletion be tried?
>
> Nandini
>
>> - Hong
>>
>>>>
>>>>
>>>>> On 9/15/09 9:51 AM, "Hong Zhang" 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\ap
>>>>> plications\j2ee-apps\alerts-central-app\alerts-central-subscribe-resp-ejb_
>>>>> jar\META-INF\maven\com.espn.alerts\alerts-central-subscribe-resp-ejb\pom.p
>>>>> roperties
>>>>>
>>>>>
>>>>> 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\ap
>>>>> plications\j2ee-apps\alerts-central-app\alerts-central-subscribe-resp-ejb_
>>>>> jar\META-INF\maven\com.espn.alerts\alerts-central-subscribe-resp-ejb\pom.p
>>>>> roperties
>>>>>
>>>>> 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" 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

[att1.html]

tjquinn
Offline
Joined: 2005-03-30
Points: 0

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

Nandini Ektare

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@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@sun.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=364624
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Comerford, Sean

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" 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@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@sun.com)]
>> >
>> > http://forums.java.net/jive/thread.jspa?messageID=364624
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> > For additional commands, e-mail: users-help@glassfish.dev.java.net
>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

--
Sean Comerford, Software Engineer
ESPN.com Site Architecture Group
Office: 860.766.6454 Cell: 860.329.5842

[att1.html]

km
Offline
Joined: 2005-10-28
Points: 0

Sean,

Where are we on this? Is a bug filed?

Regards,
Kedar

Nandini Ektare

For some reason users@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" 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" 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
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net