[
https://issues.apache.org/jira/browse/HADOOP-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041915#comment-15041915
]
Chris Nauroth commented on HADOOP-12603:
----------------------------------------
bq. certainly, if I tried to run the test on my dev linux VM, it would fail
with noatime.
That's not the behavior I'm seeing. I ran the test in a xfs mount point using
noatime, and it still passed. I hacked the test to skip deleting the data at
the end so I could inspect it manually, and it matched my expectations.
{code}
> pwd
/home/cnauroth/git/hadoop/hadoop-common-project/hadoop-common
> mount | grep '/home'
/dev/sdb1 on /home type xfs (rw,noatime,attr2,inode64,noquota)
> tree target/test/data/
target/test/data/
└── 4exGmvu2Je
├── test1
│ ├── dir
│ └── linkToDir ->
/home/cnauroth/git/hadoop/hadoop-common-project/hadoop-common/target/test/data/4exGmvu2Je/test1/dir
└── test2
5 directories, 0 files
> stat -c 'mtime=%Y atime=%X' target/test/data/4exGmvu2Je/test1/dir
mtime=2 atime=3
> stat -c 'mtime=%Y atime=%X' target/test/data/4exGmvu2Je/test1/linkToDir
mtime=1449253036 atime=1449253036
> stat -L -c 'mtime=%Y atime=%X' target/test/data/4exGmvu2Je/test1/linkToDir
mtime=2 atime=3
{code}
I can understand the concern about consistency across the whole world of OSes
and file systems though. Given that this is not a critical feature, I'm
willing to compromise and delete the tests, and let the lack of test coverage
slide. Let me know if that's how you'd like to proceed, and we can ask
[~jojochuang] to update the patch.
bq. If it makes you feel better, I've discovered yesterday that HDFS rename()
sets the modtime, but POSIX doesn't...
Two wrongs make a right. :-)
> TestSymlinkLocalFSFileContext#testSetTimesSymlinkToDir occasionally fail
> ------------------------------------------------------------------------
>
> Key: HADOOP-12603
> URL: https://issues.apache.org/jira/browse/HADOOP-12603
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Wei-Chiu Chuang
> Assignee: Wei-Chiu Chuang
> Labels: solaris, windows
> Attachments: HADOOP-12603.001.patch, HADOOP-12603.002.patch
>
>
> I have observed this test failure a few times in the past. When it fails, the
> expected access time (of the file link) is always 1000 less than the actual
> access time.
> Error Message
> {noformat}
> expected:<1448478654000> but was:<1448478655000>
> {noformat}
> Stacktrace
> {noformat}
> java.lang.AssertionError: expected:<1448478654000> but was:<1448478655000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.fs.SymlinkBaseTest.testSetTimesSymlinkToDir(SymlinkBaseTest.java:1391)
> at
> org.apache.hadoop.fs.TestSymlinkLocalFS.testSetTimesSymlinkToDir(TestSymlinkLocalFS.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {noformat}
> Standard Output
> {noformat}
> 2015-11-25 19:10:55,231 WARN fs.FileUtil (FileUtil.java:symLink(813)) -
> Command 'ln -s
> /testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test1/file
>
> /testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test2/linkToFile'
> failed 1 with: ln: failed to create symbolic link
> '/testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test2/linkToFile':
> No such file or directory
> 2015-11-25 19:10:56,212 WARN fs.FileUtil (FileUtil.java:symLink(813)) -
> Command 'ln -s
> /testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test1/file
>
> /testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test1/linkToFile'
> failed 1 with: ln: failed to create symbolic link
> '/testptch/hadoop/hadoop-common-project/hadoop-common/target/test/data/4/vae1ng5t75/test1/linkToFile':
> File exists
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
