[
https://issues.apache.org/jira/browse/HADOOP-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036554#comment-15036554
]
Chris Nauroth commented on HADOOP-12603:
----------------------------------------
The goal of HADOOP-12045 was to enable setting atime explicitly on the local
file system using the {{FileSystem#setTimes}} API. It did not get involved at
all with the automatic access time update semantics of any particular local
file system, nor did the tests include any assumptions that atime is enabled on
the local file system. I would agree that our tests cannot make assumptions
like that about the local file system.
The tests in question just need to be able to set an atime value explicitly,
and then verify that the atime was changed on the target instead of the link.
If we can get cross-platform agreement on this basic level of functionality,
then I expect we can keep the tests. There won't be any need for complexity
like checking the mount table. I think we just have a corner case bug in that
the test's call to {{FileSystem#getFileLinkStatus}} might inadvertently update
atime of the link once again. The proposed patch solves this by relaxing the
assertion to use >=.
HADOOP-12045 was implemented as a pass-through to
{{BasicFileAttributeView#setTimes}}, which then appears to be a pass-through to
[{{futimes}}|http://man7.org/linux/man-pages/man3/futimes.3.html] in
UnixNativeDispatcher.c in the OpenJDK source. On Windows, it's a pass-through
to
[{{SetFileTime}}|https://msdn.microsoft.com/en-us/library/windows/desktop/ms724933(v=vs.85).aspx]
via WindowsNativeDispatcher.c.
The Linux man page for {{futimes}} says that the function is not specified by a
standard and is only implemented for Linux and BSDs. [~alanburlison], do you
know if Solaris has {{futimes}}? I couldn't find a definitive source on that.
As long as {{BasicFileAttributeView#setTimes}} somehow works correctly onn
Solaris, then I expect we're fine.
The tests need to be skipped right now on Windows and Solaris due to a
difference in native code implementation supported by the Linux side compared
to other platforms. I described this in more detail in my comments on
HADOOP-12045. HADOOP-11935 is an open issue that would fix this problem by
using appropriate NIO APIs to get the {{stat}}/{{lstat}} behavior we need on
those platforms. I don't think we're indiscriminately skipping tests without
trying to understand semantics. We are skipping them temporarily until after
resolution of HADOOP-11935.
To summarize, I am +1 for committing patch v02, which retains the tests but
corrects for a corner case. Follow-ups are tracked in separate JIRAs. I will
hold off on committing though in case there is further discussion.
> 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)
