[
https://issues.apache.org/jira/browse/COR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272564#comment-14272564
]
Dennis E. Hamilton commented on COR-21:
---------------------------------------
I don't understand this. On initial extract to a new directory (T is created
fresh for each extract) the permissions should only be set after the files are
created.
Generally, Zip extracts do not set unusual permissions. It may be this is an
artifact of the zlib128-dll.zip containing Unix permission entries that are
being handled in some abherent way on Windows.
I suspect there is a bug and a race condition combining to cause this problem.
Note that the same script code is used to extract all of the zips, not just
zlib128-dll.zip and none of the others have this problem.
One key difference is that the zlib128-dll.zip does not have a single folder
internal to the zip as the others do. So this could also be related to the
different nesting.
I am going to dig into the zlib128-dll.zip a bit more and see what I can
discover about this.
> Extracting Externals Problems on Shared Drives
> ----------------------------------------------
>
> Key: COR-21
> URL: https://issues.apache.org/jira/browse/COR-21
> Project: Corinthia
> Issue Type: Bug
> Environment: Microsoft Windows connection to shared drives
> Reporter: Dennis E. Hamilton
> Priority: Minor
> Labels: Windows, download, scripts, sharedstorage
> Attachments: Extract-2015-01-09-1505-XPtoDitto.png,
> Extract-2015-01-09-1511-Astraendo2toDitto.png,
> Extract-2015-01-09-1523-VW10toZ.png, Extract.png
>
>
> Peter reported failures of the extract_downloads script when operating on a
> share from within a Windows 7 VMware Guest.
> A similar problem has been replicated with a Windows 10 Guest on Hyper-V.
> It smells like some sort of race condition.
> Some use on shared drives work, others fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
