4 ms·

The Rust version in fact doesn't have that problem. It opens the file, then checks the type of the open file. You could do the same in C++, but in Rust it's th

The Rust version in fact doesn't have that problem. It opens the file, then checks the type of the open file. You could do the same in C++, but in Rust it's the default. So...

acqq 6y ago
Well, I don't see that the "metadata" are actually obtained from the opened file handle in the Rust version? Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle: https://doc.rust-lang.org/std/fs/fn.metadata.html https://doc.rust-lang.org/std/fs/fn.metadata.html which says to me that the Rust version can manifest the bug of the same kind -- there are different time points in which different independent information is checked, and that all the calls correspond to the same opened file handle just can't be assured? As far as I understand only checking the properties of the opened file via the same file handle is safe for the described kind of bugs, nothing else.
- steveklabnik 6y ago
  You can get it from a File too: https://doc.rust-lang.org/std/fs/struct.File.html#method.metadata https://doc.rust-lang.org/std/fs/struct.File.html#method.met... (This doesn’t invalidate your point, of course, just saying you can do this.)
- tijsvd 6y ago
  > Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle std::fs::File::metadata operates on the open file. If the file is replaced with something else, your open file handle will still refer to the (orphaned) file, and the metadata still reflects its properties.
  - acqq 6y ago
    Then, if C++ could also obtain metadata using the file handle, and the Rust programmer must also take care to call the right "metadata" which even when it does different thing is named completely the same and as the code as written doesn't make obvious if the right overloaded metadata is called, how is Rust better? I.e. how Rust in this example helps me as a reader of the code to be sure if the right metadata function was called? Call me old fashioned, but only C is more sure to be explicit there as it wouldn't allow two different functions having the same name. If in C++ the corresponding names are also overloaded, both C and C++ "aren't cutting" if the obviousness is not there.
    - tijsvd 6y ago
      I never claimed that Rust was better in this regard, I merely pointed out that getting metadata from a path is not the only way. Filesystem handling is not trivial, and some knowledge is required beyond the language itself. I do think that File::metadata and Path::metadata make a nice API together (better than lstat, stat, and fstat). As for C not allowing two functions with the same name, sure, but then it doesn't have namespaces. In a nicely designed C library for file handling, these functions might well be called std_path_metadata and std_file_metadata, which boils down to the same thing.
      - acqq 6y ago
        You haven't answered my question? How I as a reader see which of the functions with different semantic but named the same was used in the Rust version, and how Rust helps me for that?
        tijsvd 6y ago
        Ah right. I misunderstood your question. No, Rust won't help you with that. On the contrary, Rust has excellent type inference, and in this case the name belongs to a type, which itself is inferred. As a casual reader, you'd have to track the documentation on the preceding calls.
        acqq 6y ago
        That‘s not different from C++ however.
- dgacmu 6y ago
  The rust code gets the metadata from the opened file handle, which internally uses fstat (on Unix). it would have been just as possible to write the code incorrectly by using the path version to get metadata.
tijsvd 6y ago
How is it the default in Rust? Like C++, the Rust stdlib gives you both options (std::path::Path::metadata). It boils down to calling stat vs fstat (on posix systems), and it's up to the programmer to make the right choice.
- watt 6y ago
  It's about nudging the developer to do the right thing out of the box even if they aren't really aware of all the intricacies. Ergonomic design like this will become a big deal in the future: even if you have very little idea of what you are doing the program actually will be reliable and do the right thing, provided you did not stray too far from the path the language (and the library) nudges you towards.
  - tijsvd 6y ago
    I agree that that is generally what Rust and the Rust stdlib try to do, but I don't think it holds in this case. Iterating through a directory generally yields a Path or a DirEntry, both of which have a metadata method readily available, and neither will nudge you to open the file first and then calling metadata on the open file.

The Rust version in fact doesn't have that problem. It opens the file, then checks the type of the open file. You could do the same in C++, but in Rust it's the default. So...

acqq 6y ago

Well, I don't see that the "metadata" are actually obtained from the opened file handle in the Rust version? Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle: https://doc.rust-lang.org/std/fs/fn.metadata.html https://doc.rust-lang.org/std/fs/fn.metadata.html which says to me that the Rust version can manifest the bug of the same kind -- there are different time points in which different independent information is checked, and that all the calls correspond to the same opened file handle just can't be assured? As far as I understand only checking the properties of the opened file via the same file handle is safe for the described kind of bugs, nothing else.

steveklabnik 6y ago
You can get it from a File too: https://doc.rust-lang.org/std/fs/struct.File.html#method.metadata https://doc.rust-lang.org/std/fs/struct.File.html#method.met... (This doesn’t invalidate your point, of course, just saying you can do this.)
tijsvd 6y ago
> Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle std::fs::File::metadata operates on the open file. If the file is replaced with something else, your open file handle will still refer to the (orphaned) file, and the metadata still reflects its properties.
- acqq 6y ago
  Then, if C++ could also obtain metadata using the file handle, and the Rust programmer must also take care to call the right "metadata" which even when it does different thing is named completely the same and as the code as written doesn't make obvious if the right overloaded metadata is called, how is Rust better? I.e. how Rust in this example helps me as a reader of the code to be sure if the right metadata function was called? Call me old fashioned, but only C is more sure to be explicit there as it wouldn't allow two different functions having the same name. If in C++ the corresponding names are also overloaded, both C and C++ "aren't cutting" if the obviousness is not there.
  - tijsvd 6y ago
    I never claimed that Rust was better in this regard, I merely pointed out that getting metadata from a path is not the only way. Filesystem handling is not trivial, and some knowledge is required beyond the language itself. I do think that File::metadata and Path::metadata make a nice API together (better than lstat, stat, and fstat). As for C not allowing two functions with the same name, sure, but then it doesn't have namespaces. In a nicely designed C library for file handling, these functions might well be called std_path_metadata and std_file_metadata, which boils down to the same thing.
    - acqq 6y ago
      You haven't answered my question? How I as a reader see which of the functions with different semantic but named the same was used in the Rust version, and how Rust helps me for that?
      - tijsvd 6y ago
        Ah right. I misunderstood your question. No, Rust won't help you with that. On the contrary, Rust has excellent type inference, and in this case the name belongs to a type, which itself is inferred. As a casual reader, you'd have to track the documentation on the preceding calls.
        acqq 6y ago
        That‘s not different from C++ however.
dgacmu 6y ago
The rust code gets the metadata from the opened file handle, which internally uses fstat (on Unix). it would have been just as possible to write the code incorrectly by using the path version to get metadata.

tijsvd 6y ago

How is it the default in Rust? Like C++, the Rust stdlib gives you both options (std::path::Path::metadata). It boils down to calling stat vs fstat (on posix systems), and it's up to the programmer to make the right choice.

watt 6y ago
It's about nudging the developer to do the right thing out of the box even if they aren't really aware of all the intricacies. Ergonomic design like this will become a big deal in the future: even if you have very little idea of what you are doing the program actually will be reliable and do the right thing, provided you did not stray too far from the path the language (and the library) nudges you towards.
- tijsvd 6y ago
  I agree that that is generally what Rust and the Rust stdlib try to do, but I don't think it holds in this case. Iterating through a directory generally yields a Path or a DirEntry, both of which have a metadata method readily available, and neither will nudge you to open the file first and then calling metadata on the open file.