[
https://issues.apache.org/jira/browse/HDFS-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291695#comment-14291695
]
Steve Loughran commented on HDFS-7665:
--------------------------------------
The second of those, {{src/site/markdown/filesystem}} is where I'd like it
done; something which says "this is what truncate()" does, this is the valid
state before and after, here are the exceptions you should/must throw, and here
is the state afterwards.
Once that's done, deriving a new subclass of {{AbstractFSContract}} purely to
test truncate operations becomes straightforward: all a new contract test
option to declare whether or not an FS supports truncate, and if it does, feed
it valid data & expect a valid response, then feed it invalid & corner case
data and expect failures.
It's probably wise to mention the lack of guarantees about concurrent access,
e.g. "if an input stream is open when truncate() occurs, the outcome of all
operations other than {{close()}} on that stream are undefined.
> Add definition of truncate preconditions/postconditions to filesystem
> specification
> -----------------------------------------------------------------------------------
>
> Key: HDFS-7665
> URL: https://issues.apache.org/jira/browse/HDFS-7665
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: documentation
> Affects Versions: 3.0.0
> Reporter: Steve Loughran
> Fix For: 3.0.0
>
>
> With the addition of a major new feature to filesystems, the filesystem
> specification in hadoop-common/site is now out of sync.
> This means that
> # there's no strict specification of what it should do
> # you can't derive tests from that specification
> # other people trying to implement the API will have to infer what to do from
> the HDFS source
> # there's no way to decide whether or not the HDFS implementation does what
> it is intended.
> # without matching tests against the raw local FS, differences between the
> HDFS impl and the Posix standard one won't be caught until it is potentially
> too late to fix.
> The operation should be relatively easy to define (after a truncate, the
> files bytes [0...len-1] must equal the original bytes, length(file)==len, etc)
> The truncate tests already written could then be pulled up into contract
> tests which any filesystem implementation can run against.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
