[
https://issues.apache.org/jira/browse/GOBBLIN-2082?focusedWorklogId=922670&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922670
]
ASF GitHub Bot logged work on GOBBLIN-2082:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Jun/24 21:28
Start Date: 07/Jun/24 21:28
Worklog Time Spent: 10m
Work Description: Will-Lo opened a new pull request, #3966:
URL: https://github.com/apache/gobblin/pull/3966
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I
have checked off all the steps below!
### JIRA
- [ ] My PR addresses the following [Gobblin
JIRA](https://issues.apache.org/jira/browse/GOBBLIN/) issues and references
them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"
- https://issues.apache.org/jira/browse/GOBBLIN-2071
### Description
- [ ] Here are some details about my PR, including screenshots (if
applicable):
Manifest distcp often creates large file directory structures when copying
files from one location to another. There is a risk when concurrently
publishing files from a directory structure where the folders may not exist
before renaming files, described by the javadoc:
```
* Renames a src {@link Path} on fs {@link FileSystem} to a dst {@link Path}.
If fs is a {@link LocalFileSystem} and
* src is a directory then {@link File#renameTo} is called directly to avoid
a directory rename race condition where
* {@link org.apache.hadoop.fs.RawLocalFileSystem#rename} copies the
conflicting src directory into dst resulting in
* an extra nested level, such as /root/a/b/c/e/e where e is repeated.
```
Given that on HDFS it does not use a RawLocalFileSystem in many
implementations, we want to pre-create the folders copied sequentially to
safely create the folders before publishing the files.
This PR changes `SetPermissionCommitStep` to
`CreateAndSetDirectoryPermissionCommitStep` which also creates folders BEFORE
the commit is completed, instead of after.
### Tests
- [x] My PR adds the following unit tests __OR__ does not need testing for
this extremely good reason:
unit tests
### Commits
- [ ] My commits all reference JIRA issues in their subject lines, and I
have squashed multiple commits if they address the same issue. In addition, my
commits follow the guidelines from "[How to write a good git commit
message](http://chris.beams.io/posts/git-commit/)":
1. Subject is separated from body by a blank line
2. Subject is limited to 50 characters
3. Subject does not end with a period
4. Subject uses the imperative mood ("add", not "adding")
5. Body wraps at 72 characters
6. Body explains "what" and "why", not "how"
Issue Time Tracking
-------------------
Worklog Id: (was: 922670)
Remaining Estimate: 0h
Time Spent: 10m
> Manifest distcp creates extra folders when publishing files
> -----------------------------------------------------------
>
> Key: GOBBLIN-2082
> URL: https://issues.apache.org/jira/browse/GOBBLIN-2082
> Project: Apache Gobblin
> Issue Type: Bug
> Components: gobblin-core
> Reporter: William Lo
> Assignee: Abhishek Tiwari
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Manifest distcp often creates large file directory structures when copying
> files from one location to another. There is a risk when concurrently
> publishing files from a directory structure where the folders may not exist
> before renaming files, described by the javadoc:
> {code:java}
> * Renames a src {@link Path} on fs {@link FileSystem} to a dst {@link Path}.
> If fs is a {@link LocalFileSystem} and
> * src is a directory then {@link File#renameTo} is called directly to avoid a
> directory rename race condition where
> * {@link org.apache.hadoop.fs.RawLocalFileSystem#rename} copies the
> conflicting src directory into dst resulting in
> * an extra nested level, such as /root/a/b/c/e/e where e is repeated. {code}
> Given that on HDFS it does not use a RawLocalFileSystem in many
> implementations, we want to pre-create the folders copied sequentially to
> safely create the folders before publishing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
