Poll: .NET Pop Quiz

Buddy

What should the function do when you pass it something that's not a valid separator?

ben_lubar

What string isn't a valid separator? Even empty string is valid - that means "split the string with one character per output string"

Buddy

Show me the POSIX standard where it says that.

ben_lubar

There's a POSIX standard for "function that splits string on separator"?

Buddy

No, but there is one for path elements.

ben_lubar

Join joins any number of path elements into a single path, adding a Separator if necessary. The result is Cleaned, in particular all empty strings are ignored.

const (
        Separator     = os.PathSeparator
        ListSeparator = os.PathListSeparator
)

Clean returns the shortest path name equivalent to path by purely lexical processing. It applies the following rules iteratively until no further processing can be done:

Replace multiple Separator elements with a single one.

Eliminate each . path name element (the current directory).

Eliminate each inner .. path name element (the parent directory) along with the non-.. element that precedes it.

Eliminate .. elements that begin a rooted path: that is, replace "/.." by "/" at the beginning of a path, assuming Separator is '/'.

The returned path ends in a slash only if it represents a root directory, such as "/" on Unix or C:\ on Windows.

If the result of this process is an empty string, Clean returns the string ".".

See also Rob Pike, “Lexical File Names in Plan 9 or Getting Dot-Dot Right,” http://plan9.bell-labs.com/sys/doc/lexnames.html

Buddy

..

FrostCat

I hereby award Ben these s

ben_lubar

Gophers don't have feathers.

FrostCat

I'm not sure if you just outed yourself as a furry or not, but you have feathers because I just gave 'em to you. They're right there, two post up.

powerlord

@ben_lubar said:

There's a POSIX standard for "function that splits string on separator"?

Yes.

I know you were joking, but strtok really is part of the POSIX standard AKA IEEE 1003.1.

flabdablet

@ben_lubar said:

What if you want to find the oldest file in a directory by brute forcing it? You'll always get a nonexistent file.

Yeah, but by the time your function has finished its search the Sun will have swallowed the Earth, so it probably doesn't matter.

Is anybody else seeing their browser spelling check language gratuitiously set to Kazakh?

loose

No, but when I installed a common plugin for my IDE, from the [plugin].org website, all the tool tips were in Russian.

loose

I responded to the spirit of the post and picked the most unlikely answer. Given the circumstances of it's "use" (which I did not know in detail, at the time).

@Ragnax said:

That's what should be thrown if you'd have insufficient permission to access the last write time on a file or insufficient permission to access the file in general.

It would seem potentially possible as "who does have permission to access a FILE_NOT_FOUND ?"

Ragnax

@loose said:

It would seem potentially possible as "who does have permission to access a FILE_NOT_FOUND ?"

Strictly speaking, that is a file-system dependent critirium, actually, and one that is made quite interesting by the existence of filesystems that cascade access permissions. Taking NTFS as an example:

In NTFS everyone that is granted read access to a folder via its ACL is by default recursively given read access to the underlying folders and files.
(Note that in truth, things are a bit more complex with both allow and deny entries and the fact that a user can belong to multiple groups that combine both type of entries. But let's forego that for a bit, lest we go cross-eyed...)

As a non-existent file also has no ACL to speak of, technically everyone that has access to its parent folder also has access to read the non-existent properties of the non-existent file as well. If parent folders also do not exist that relation recurses all the way back up to the root of the tree, a.k.a. the volume root, to which typically all users have read access.

An explicit FileNotFoundException is imho still the only correct exception to throw when attempting to fetch meta-data on a non-existent file if you want to guarantee any kind of predictability. ;)

PleegWat

On the other hand, on a system like ext which does not have cascading access permission, you get access denied if you do not have execute access to one of the intervening directories. Note you do not need read access to traverse directories; you only need that to list them. See man 2 stat or man 7 path_resolution for a full list of possible error conditions.

Buddy

How does windows go treat filepath.Join("C:\\Windows", "C:\\System32")?

ben_lubar

I'm going to guess C:\Windows\C:\System32, but I haven't tested it.

Planar

@blakeyrat said:

Oh no, I saw that, but it's kind of negated by the fact that you still typed the fucking question. If you agree with my point, then why the fuck are you asking!? Christ.

Why do people ask questions, usually?

Buddy

Hence my ‘equally incorrect’ comment. I would like to point out that technically that statement doesn't imply any specific level of wrongness, just that however much you dislike that Windows result, you should dislike the Linux analog equally.

Steve_The_Cynic

@ben_lubar said:

Isn't the opposite true? Windows doesn't recognize it in some cases, but NTFS allows either '\' or '/' interchangeably?

No. NTFS elements don't contain either of them. The Windows APIs, depending on how you use them, do or do not allow the use of forward slashes.

Specifically (using the two versions of CreateFile():

CreateFileA() takes normal ("multibyte", but not UTF-8) characters, and allows '/' and '\\' as separators, regardless of the underlying file system. It will also parse away consecutive separators and other gobble. The length of the input string is limited to MAX_PATH (260) characters.
CreateFileW(), when given a path that does not begin backslash-backslash-dot-backslash, does the same as CreateFileA() except that it allows L'/' and L'\\' as separators because it takes "Unicode" (BMP-only UTF-16) characters.
CreateFileW(), when given a path that does begin backslash-backslash-dot-backslash, expects the rest of the path to be a fully-parsed absolute path without dot-dot sequences and with only canonical separators, that is, only L'\\'. In this mode, it does none of the interpretation, expansion, and so on that it does in the previously mentioned modes. Why would you use this mode, though? That is simple. In this mode, it allows up to 32767 characters in the fully-parsed path.

PleegWat

@ben_lubar said:

I'm going to guess C:\Windows\C:\System32, but I haven't tested it.

That's not a valid windows path. : is reserved.