Files.getNameWithoutExtension removes file name for hidden file

[GoogleCodeExporter]

Files.getNameWithoutExtension("a/.hidden") returns an empty string. The result 
for "basename a/.hidden .hidden" keeps the file name and returns ".hidden".

The same problem may apply to Files.getFileExtension: 
Files.getFileExtension("a/.hidden") returns "hidden" as the file extension.

Original issue reported on code.google.com by thomas.a...@gmail.com on 31 Aug 2012 at 7:15

[GoogleCodeExporter]

Interesting.  The current behavior is "intentional" in that we're aware of it 
and that we have tests for the current behavior.  (FilesTest.java is still tied 
up with some internal infrastructure, so we haven't released it yet :\)  Is it 
"right?"  Hard to say.

Here's the relevant bit of POSIX on basename:

"If the suffix operand is present, is not identical to the characters remaining 
in string, and is identical to a suffix of the characters remaining in string, 
the suffix suffix shall be removed from string."
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/basename.html

This raises a few questions:

1. Is getNameWithoutExtension an implementation of basename (well, an 
implementation of basename with the suffix automatically set to the file 
extension)?  We already deviate from basename in at least one way: We map / to 
"" instead of to /.

2. Is it even desirable to be an implementation of basename?  Coincidentally, I 
just yesterday heard a separate horror story about how POSIX is often more 
about documenting existing behavior than about selecting "good" behavior.  You 
can see shades of this in the linked basename doc: // is permitted to be mapped 
to //, but any other nonzero number of slashes is required to be mapped to /.

Probably the right question is "What counts as an 'extension?'" but I doubt 
that something like that is officially defined anywhere.

Original comment by cpov...@google.com on 31 Aug 2012 at 4:17

• Changed state: Research
• Added labels: Package-IO

[GoogleCodeExporter]

I'm inclined to think that the least surprising behavior is to treat dots 
appearing at the start of the filename differently from dots appearing later. 
Specifically, if the filename is ".." or the last index of "." is 0, I think we 
should consider there to be no extension.

Original comment by cgdec...@gmail.com on 31 Aug 2012 at 9:56

[GoogleCodeExporter]

We'll either change the implementation or clarify the docs accordingly.

Original comment by kak@google.com on 23 Oct 2012 at 4:59

• Changed state: Accepted

[GoogleCodeExporter]

Here's my opinion:

- getNameWithoutExtension isn't and shouldn't try to be an implementation of 
basename. It and getFileExtension should just be methods with well-defined 
semantics for handling filenames that match user expectations as closely as 
possible (obviously, that last part may be somewhat subjective, but I think 
that's probably OK as long as the semantics are spelled out).
- Filenames starting with a "." are pretty common and generally understood to 
be hidden files, not a files that only have an extension.

I say we define extension such that a "." at the start of a name cannot be the 
extension separator and change behavior of both methods dealing with extensions 
to match.

Original comment by cgdecker@google.com on 24 Oct 2012 at 10:12

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:18

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit