D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 7001 - std.path.baseName and isValidFilename wrong documentation
Summary: std.path.baseName and isValidFilename wrong documentation
Status: RESOLVED INVALID
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: Other Windows
: P2 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-24 12:59 UTC by Andrej Mitrovic
Modified: 2012-02-01 14:33 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Andrej Mitrovic 2011-11-24 12:59:09 UTC
"Returns the name of a file, without any leading directory and with an optional suffix chopped off. "

It should be:
Returns the name of a file *or directory*, without any leading directory and with an optional suffix chopped off. 

Note the assert:
assert (baseName("dir/subdir/") == "subdir");

Secondly:
isValidFilename
"Checks that the given file or directory name is valid. "
should be:
"Checks that the given file name is valid."

It does *not* verify directory names, only filenames.
Comment 1 Andrej Mitrovic 2011-11-24 13:00:44 UTC
(In reply to comment #0)
> "Returns the name of a file, without any leading directory and with an optional
> suffix chopped off. "
> 
> It should be:
> Returns the name of a file *or directory*, without any leading directory and
> with an optional suffix chopped off. 
> 

That refers to std.path.baseName.
Comment 2 Jonathan M Davis 2011-12-06 21:05:51 UTC
And how does isValidFilename not validate directory names?

There's no really zero difference between a file and a directory as far as paths go except anything to the left of the rightmost directory separator must be a directory or drive. I believe that both std.path and std.file have a tendancy to use the term file even when it applies to directories - which is fairly typical in such documentation, I believe - though in some cases it can be confusing. Already, as far Posix is concerned, what you'd typically refer to as a file would be a "regular" file rather than a file.

In any case, baseName is arguably correct as-is, though it certainly wouldn't hurt to add "or directory" to it, and I don't see what's incorrect about isValidFilename. It validates a file or directory name. The only complaint in that regard that I can think of that you might be making is the fact that something like "dir/" would return false for it, and since directory separators are invalid in both directory and file names, I don't see that as a problem. So, unless you have another argument that I can't think of, I don't know what your issue with isValidFilename could be.
Comment 3 Andrej Mitrovic 2011-12-06 23:00:04 UTC
(In reply to comment #2)
> and since directory separators
> are invalid in both directory and file names

Why are they invalid in directory names?
Comment 4 Jonathan M Davis 2011-12-06 23:14:01 UTC
If you have /dir or dir/, the name of the directory is dir, not /dir, or dir/. It is illegal on Posix systems to have a directory name with / in it, just like it's illegal on Windows systems to have a directory name with \ in it. A _path_ can have the directory separator for the current OS in it, but not a file or directory name, and isValidFilename is checking file _names_, not paths.
Comment 5 Lars T. Kyllingstad 2011-12-26 11:37:55 UTC
Here, "file" means a node in a file system, and it encompasses normal files as well as directories, symbolic links, named pipes, device files and sockets.

In that sense, "file or directory" may be redundant.
Comment 6 Jonathan M Davis 2011-12-26 14:02:45 UTC
I believe that Posix at least uses the term regular file for normal files, and then still uses the term file for everything. It _can_ be a bit confusing, but I don't know a better way to go about it. Unfortunately, the term file can be ambiguous due to differences in its usage.
Comment 7 Lars T. Kyllingstad 2012-02-01 14:33:48 UTC
It seems the confusion has been cleared up, so I'm closing this.  If anyone still disagrees, please reopen.