32 ms·

I don't think that the Rust version is as different as the author seems to believe. For example: the author writes "What happens if the file has been replaced

by acqq 6y ago

I don't think that the Rust version is as different as the author seems to believe. For example: the author writes "What happens if the file has been replaced by, e.g., a pipe or other not regular_file?" But it seems to me that the same problem -- replacing the file which is regular during the directory walk with the pipe exactly before the said pipe is opened -- can exist in Rust version too. It doesn't matter how the syntax looks like, I suspect the equivalent system calls are the same, Rust will also walk the directory at T1 obtaining metainformation, at T2 open the file, even if it is at that moment actually a pipe, and then at T3 check if the metainformation obtained at T1 is a regular file ("file" in the source?), which could still be that? That says to me that the both version can suffer from the same bug. Luckily it's something that's not going to happen too often in practice, knowing how typical programs don't use the same file name for a pipe and a file in rapid succession.

Filligree 6y ago
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.
- 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.

by acqq 6y ago

Filligree 6y ago

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.
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.