commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] [Commented] (IO-567) FilenameUtils is unaware of NTFS alternate data streams
Date Tue, 30 Jan 2018 22:44:00 GMT


Sebb commented on IO-567:

AFAICT only the part before the colon is returned in directory searches etc, so the file name
would have to come from elsewhere.
i.e. it should be sanitised by the caller before use.

> FilenameUtils is unaware of NTFS alternate data streams
> -------------------------------------------------------
>                 Key: IO-567
>                 URL:
>             Project: Commons IO
>          Issue Type: Bug
>            Reporter: Jochen Wiedmann
>            Assignee: Jochen Wiedmann
>            Priority: Minor
> Windows NTFS has a feature, called ADS (Alternate Data Streams). Basically, it works
like this: Traditionally, a file called "foo" consists of a byte stream, which can be read,if
we open the file "foo". Not so with NTFS. A file may have other byte streams, the so-called
alternate data streams. These are addressed by using file names like "foo:alternate_stream_name".
(Colon as a separator.)
> While that is not a problem in itself, it may become difficult in connection with file
name extensions. As you know, these have a special meaning on Windows. A .exe file may be
executed. Thus, a .exe file with unknown contents would be dangerous. In the case of NTFS,
this must be rephrased: A .exe file with unknown contents in its default data stream would
be dangerous.
> Now consider the case of a name like "foo.exe:bar.txt". This would be the alternate data
stream named "bar.txt" in a file, named "foo.exe". If that name is passed to FilenameUtils.getExtension(String),
it would happily return ".txt", although the Windows Explorer, or whatever other tool would
show us "foo.exe".
> Commons IO should implement special case handling for this in FilenameUtils.getExtension(String),
and FilenameUtils.indexOfExtension(String)
> Suggestion:
>     a) Document the problem in Javadoc, and
>     b) Throw an IllegalArgumentException, if the file name contains a ':'.

This message was sent by Atlassian JIRA

View raw message