| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* maint:
filename: Add safe_relative_path/1
Conflicts:
lib/stdlib/src/filename.erl
|
|
Add safe_relative_path/1 to guard against directory traversal
attacks. It either returns a shorter path without any ".." or
"." components, or 'unsafe' if an ".." component would climb
up above the root of the relative path. Here are a few
examples:
safe_relative_path("a/b/..") => "a"
safe_relative_path("a/..") => ""
safe_relative_path("a/../..") => unsafe
safe_relative_path("/absolute/path") => unsafe
The returned path can be used directly or combined with an
absolute path using filename:join/2.
|
|
|
|
This moves, extends and exports functionality that previously existed only
internally in filename:find_src/1/2, adding the ability to automatically
substitute file suffixes and use different rules for different suffixes.
|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
Handle the case when the environment APPDATA is not set.
|
|
|
|
|
|
|
|
filename:split("") returns [], while filename:split(<<"">>) returns
[<<"/">>].
Since the support in the filename module for binary arguments is
much more recent than support for strings, change
filename:split(<<"">>) so that it returns [].
Noticed-by: KOUCHANG
|
|
The reference manual says that filename:join(A,B) is equivalent to
filename:join([A,B]). In some rare cases this turns out not to be
true:
1> filename:join("/a/.","b").
"/a/./b"
2> filename:join(["/a/.","b"]).
"/a/b"
In general, filename:join/1,2 removes single dots from the resulting
path, except dots that occur at the beginning or end of the path. The
problem above occurs when the first argument to join/2 ends with a
dot, then it is not removed even if the second argument differs from
an empty string and thus the dot ends up in "the middle" of the path.
This commit corrects this problem. A single dot is now only kept if it
occurs at the very beginning or the very end of the resulting path.
Test of filename:join/1,2 are added in filename_SUITE. In addition,
filelib_SUITE is updated with more tests of filelib:wildcard/2 since
this failed when the given current directory (second argument) ended
with a dot.
|
|
This port has support for both non-smp and smp.
It contains a new way to do io checking in which erts_poll_wait
receives the payload of the polled entity. This has implications
for all linked-in drivers.
|
|
|
|
The recommended type for filenames is a list of characters (which
may be Unicode characters greater than 255). Change the
file:filename() to reflect that.
For the filename module we still need a type that can be either
a string or a binary, so we need to introduce the type
file:filename_all().
|
|
|
|
os:type/0 always returns a two-tuple.
|
|
|
|
|
|
Don't choke on paths given as binary argument on Win32.
|
|
filename:find_src/1,2 will crash when asked to find the source
corresponding to a BEAM with no compilation options. A BEAM file
can be missing compilation options if it has been stripped using
beam_lib:strip/1 or compiled using the undocumented 'slim' option.
Why this matters: If ERL_COMPILE_OPTIONS is set to +slim before
building Erlang/OTP, there will be a crash in 'igor' during the
building of the public_key application. ('igor' merges several
source code files, and uses filename:find_src/1,2 to find the
source code.)
Change filename:find_src/1,2 to return an empty option list if
there are no options in the BEAM file.
Noticed-by: Per Hedeland
|
|
Mod:module_info(source_file) is no longer supported (and have not
been for a long time), so calling it will always fail.
|
|
The 'trace' and 'fast' options are no longer supported.
While at it, correct the comment about option filtering.
|
|
In most cases, we can simply return a tail of the flattened
filename.
|
|
Simply return a tail of the flattened filename.
|
|
|
|
|
|
|
|
|
|
|
|
* ks/types:
file.hrl: Move out type declarations
kernel: Add types and specs
OTP-8494 ks/types
|
|
Having various type declarations in the file.hrl file was once upon a time
necessary since the system could not really handle remote types. Now it can
and these declarations should not be there but appear in file.erl instead.
This means that files that need to use these types can refer to them using
a remote type reference, and not having to include file.hrl - at least not
for this reason.
|
|
|
