ayushtkn commented on pull request #2061:
URL: https://github.com/apache/hadoop/pull/2061#issuecomment-641559980
Thanx @umamaheswararao the test is really helpful. I tried it and found
really the filestatus are different in case of HDFS as well :
```
Through ListStatus
HdfsLocatedFileStatus{path=hdfs://localhost:42219/links/linkDir;
isDirectory=false; length=0; replication=0; blocksize=0;
modification_time=1591733953915; access_time=1591733953915; owner=ayush;
group=supergroup; permission=rwxrwxrwx; isSymlink=true;
symlink=/user/targetRegularDir; hasAcl=false; isEncrypted=false;
isErasureCoded=false}
Through getFileStatus
HdfsLocatedFileStatus{path=hdfs://localhost:42219/user/targetRegularDir;
isDirectory=true; modification_time=1591733953674; access_time=0; owner=ayushS;
group=hadoop; permission=rwxr-xr-x; isSymlink=false; hasAcl=false;
isEncrypted=false; isErasureCoded=false}
```
>Probably we should just clarify the behavior in user guide and API docs
about the behaviors in symlinks case? Otherwise fixing this needs to be done
all other places and it will be incompatible change across.
Yahh, Documenting this properly sounds most apt as of now.
>One advantage I see with the existing behavior is that, with listStatus we
can know dir is symlink. If one wants to know targetFs details, then issue
GetFileStatus on that path will resolved to targetFS and gets the FileStatus at
targetFS.
Correct, provided people know about this behavior, this behavior may be
helpful in many places . but there is probably too much lack of
documentation/awareness around symlinks,
> we see Ambari Files View is blocked due to this for ViewFS .
If we don't fix this, Srinivasu Majeti's problem won't get solved?
But if there aren't any further different opinions, and provided HDFS is
also behaving similarlly, we don't have much scope changing just in ViewFs, So
documenting properly as you said should be our final option.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
