[
https://issues.apache.org/jira/browse/HDFS-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Collins updated HDFS-860:
-----------------------------
Target Version/s: 2.0.0
Details of how this fails on linux:
{noformat}
~ $ scp temp localhost:/mnt/fuse-dfs/user/eli/
temp 100% 6 0.0KB/s 00:00
scp: /mnt/fuse-dfs/user/eli//temp: truncate: Operation not supported
{noformat}
{noformat}
write[139718171864544] 6 bytes to 0 flags: 0x8001
write[139718171864544] 6 bytes to 0
unique: 168, success, outsize: 24
unique: 169, opcode: SETATTR (4), nodeid: 7, insize: 128
truncate /user/eli/temp 6
unique: 169, error: -95 (Operation not supported), outsize: 16
unique: 170, opcode: FLUSH (25), nodeid: 7, insize: 64
{noformat}
Brian is right wrt #2, the hdfsFileInfo obtained by libhdfs will report size ==
0 because we have yet to close the file, and we don't have an interface to get
the size of the file according to the client. The attached patch gets scp to a
fuse mount working for me so I'm going to commit this per my earlier +1, filed
HDFS-3431 to improve truncate per the comments.
> fuse-dfs truncate behavior causes issues with scp
> -------------------------------------------------
>
> Key: HDFS-860
> URL: https://issues.apache.org/jira/browse/HDFS-860
> Project: Hadoop HDFS
> Issue Type: Wish
> Components: contrib/fuse-dfs
> Reporter: Brian Bockelman
> Assignee: Brian Bockelman
> Priority: Minor
> Attachments: HDFS-860.patch, hdfs-860.txt
>
>
> For whatever reason, scp issues a "truncate" once it's written a file to
> truncate the file to the # of bytes it has written (i.e., if a file is X
> bytes, it calls truncate(X)).
> This fails on the current fuse-dfs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
