This commit makes a slight change to the vfs_posix test suite to let it
pass on Android.
On Android, non-root processes can perform most filesystem operations
only on a restricted set of directories. The vfs_posix test suite
attempted to enumerate the filesystem root directory, and said directory
happens to be restricted for non-root processes. This would raise
an EACCES OSError and terminate the test with a unexpected failure.
To fix this, rather than enumerating the filesystem root directory the
enumeration target is the internal shared storage area root - which
doesn't have enumeration restrictions for non-root processes. The path
is hardcoded because it is guaranteed to be there on pretty much any
recent-ish device for now (it stayed the same for more than a decade for
compatibility reasons). The proper way would be to query the storage
subsystem via a JNI round-trip call, but this introduces too much
complexity for something that is unlikely to break going forward.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
These tests test an unrealistic situation and only pass by accident due
to a bug. The upcoming fix for the bug would make them fail.
The unrealistic situation is that VfsPosix methods are called with
relative paths while the current working directory is somewhere outside
of the root of the VFS. In the intended use of VFS objects via
os.mount() (as opposed to calling methods directly as the tests do),
this never happens, as mp_vfs_lookup_path() directs incoming calls to
the VFS that contains the CWD.
Make the testing situation realistic by changing the working directory
to the root of the VFS before calling methods on it, as the subsequent
relative path accesses expect.
Thanks to the preceding commit, the tests still pass, but still for the
wrong reason. The following commit "Fix relative paths on non-root VFS"
will make them pass for the correct reason.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
A VfsPosix created with a relative root path would get confused when
chdir() was called on it and become unable to properly resolve absolute
paths, because changing directories effectively shifted its root. The
simplest fix for that would be to say "don't do that", but since the
unit tests themselves do it, fix it by making a relative path absolute
before storing it.
Signed-off-by: Christian Walther <cwalther@gmx.ch>
Prevent handle leaks when file objects aren't closed explicitly and
fix some MICROPY_CPYTHON_COMPAT issues: this wasn't properly adhered
to because #ifdef was used so it was always on, and closing files
multiple times should be avoided unconditionally.
On ports with more than one filesystem, the type will be wrong, for example
if using LFS but FAT enabled, then the type will be FAT. So it's not
possible to use these classes to identify a file object type.
Furthermore, constructing an io.FileIO currently crashes on FAT, and
make_new isn't supported on LFS.
And the io.TextIOWrapper class does not match CPython at all.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
