hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-2025) Instantiating a FileSystem object should guarantee the existence of the working directory
Date Wed, 14 Nov 2007 19:47:43 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542566
] 

Chris Douglas commented on HADOOP-2025:
---------------------------------------

The changes to the test code were to accommodate the Trash- which attempts to use the working
directory if the default path isn't absolute- in tests (TestReplicationPolicy, MiniDFSCluster),
correcting a transaction count that was thrown off by creating a working directory in MiniDFSCluster
(TestEditLog), and accommodating the new semantics of setWorkingDirectory (TestLocalDFS).
If there's a less kludgy way to pass the first and second tests, I'd be open to it.

bq. Not sure what you mean. Do you have reservations about this approach?

Not with the approach, but this impl wasn't fitting well with cases like that in HADOOP-1916,
where FsShell might create a default working dir if it didn't exist. This is cleanly solved
by adding the FileSystem::getDefaultWorkingDir() method you suggested. I'll rework the patch.

Do you prefer throwing an IOException to an IllegalArgumentException in setWorkingDirectory?
I went back and forth on that, but ultimately wanted to distinguish between problems with
FileSystem::exists() and a non-existent path (e.g. RawInMemoryFileSystem).

> Instantiating a FileSystem object should guarantee the existence of the working directory
> -----------------------------------------------------------------------------------------
>
>                 Key: HADOOP-2025
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2025
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: fs
>    Affects Versions: 0.14.1
>            Reporter: Sameer Paranjpye
>             Fix For: 0.16.0
>
>         Attachments: 2025.patch
>
>
> Issues like HADOOP-1891 and HADOOP-1916 illustrate the need for this behavior.
> In HADOOP-1916 the problem is that the default working directory for a user on HDFS '/user/<username>'
does not exist. This results in the command 'hadoop dfs -copyFromLocal foo ." creating a *file*
called /user/<username> and copying the contents of the file 'foo' into this file.
> HADOOP-1891 is basically the same problem. The problem that Olga observed was that copying
a file to '.' on HDFS when her 'home directory' did not exist resulted in the creation of
a file with the path as her home directory. The problem is incorrectly filed as a bug in the
Path class. The behavior of Path is correct, as Doug points out, it is perfectly reasonable
for Path(".") to convert to an empty path. When this empty path is resolved in HDFS or any
other filesystem the resolution to '/user/<username>' is also correct (at least for
HDFS). The problem IMO is that the existence of the working directory is not guaranteed.
> When I log in to a machine my default working directory is '/home/sameerp' and filesystem
operations that I execute with relative paths all work correctly because this directory exists.
My home directory lives on a filer, in the event of it being unmountable the default working
directory I get is '/' which also is guaranteed to exist.
> In the context of Hadoop, instantiating a FileSystem object is the analogue of logging
in and should result in a working directory whose existence has been validated. In the case
of HDFS this should be '/user/<username>' or '/' if the directory does not exist.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message