Bugzilla – Full Text Bug Listing
| Summary: | [Functionality] File deployment fails if destination is a mapped drive and AC is run as service | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Kevin Mooney <kmooney> |
| Component: | TPTP | Assignee: | Joe Toomey <jptoomey> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | jptoomey, paulslau |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Kevin Mooney
Left severity at normal only due to assumption that use of mapped drives for this purpose is not a common configuration, nor is this a regression. Otherwise this would be a high severity defect with higher priority. Scott, please re-assign as appropriate if this turns out to be platform issue. May be related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4938442 If so, we should trap this error and copy the file in smaller chunks. Upgrading severity to lobby for 4.2.1 Discussed this with Kent and agreed to defer to 4.3 Per AG call on 10/20, all non-blocking/non-critical defects are to be retargeted to 4.4. Has the priority for this defect been recently reviewed given its severity? If not, please take a few minutes and reevaluate the priority. Increasing the priority to P1 since including in the 4.4 plan. Increasing the priority to P1 since including in the 4.4 plan. Assigning target. This defect is a candidate for deferral from the 4.4 release. If the originator has opposition, please provide an argument against this deferral. Assigning to i4 since i3 is complete but this defect belongs to a block of in-plan 4.4 defects that are candidates for deferral. I have tried reproducing this as described, and I'm not able to make it fail. I have created a workspace on a mapped drive (z:\mappedWorkspace, which lives on a remote machine), and created a JUnit test in a new project in that workspace. I have verified that the testsuite really lives on that mapped drive, and I artificially inflated the size of the test suite (to ~29MB) to ensure the problem wasn't file size. Deployment and execution still work for me. I discussed this with Kevin, and I'm closing this as WORKSFORME for now. Kevin is going to investigate further in the consuming product, and if he concludes that the problem is in TPTP code, I'll debug TPTP within the consuming product. Reporter: Please verify and close in preparation for shutting down the TPTP 4.4 release. Thanks. This problem still occurs for consuming product failing in file services. Joe will investigate today this issue. Re-targetting to the next maintenance release (4.4.1). Further investigation shows that this problem is specific to AC running as a service. The root cause of this is that services are unable to access mapped drives in windows (XP and above). Actually, that's a bit of an exaggeration. In truth, mapped drives are managed independently in windows XP and above for each login (and with multiple concurrent logins, each user can see only his/her drive mappings and not other users' mappings.) Since services run in a different login, they can not access drive mappings done in a user login. A service can still access a mapped drive in XP if the mapping was created by the service login session (though this will never be the case for our users, since that means the AC would have to map the drive.) From what I have read, this was a behavior change between Win2k (where services could access mapped drives) and XP (where they no longer are able to.) http://msdn2.microsoft.com/en-us/library/ms685143.aspx Closing this defect as invalid (doesn't make sense to mark as WONTFIX -- it's really more CANTFIX). Closing by default since not closed by the originator in the 7+ months since being resolved. Please reopen if the issue is still present in the latest TPTP release or the resolution is not correct. |