4 ms·

Is stat really something you want as an abstraction over all filesystems? You might not even have that information available in all of them.

heinrichhartman 6y ago
Calling stat on all the files is just really expensive if your directly is large.
- networkimprov 6y ago
  See the Reddit for an alternative to FileInfo. https://www.reddit.com/r/golang/comments/hv976o/qa_iofs_draft_design/ https://www.reddit.com/r/golang/comments/hv976o/qa_iofs_draf...
- tptacek 6y ago
  FileInfo is an interface, isn't it? You could populate fields other than "name" lazily, right?
  - TheDong 6y ago
    You can't because the interface doesn't allow any errors. Lazily populating data is usually fallible, and the interface's methods are all infallible.
    - tptacek 6y ago
      OK, I'm convinced. Not a great interface, should just return an iterator.
skissane 6y ago
Every filesystem ever has the concept of file attributes. The problem is the exact details of what file attributes are supported vary widely from system to system. The best approach is to support a subset which is reasonably common across platforms – file type[1], modification timestamps, file size in bytes, etc – and an extension mechanism to enable platform-specific attributes. Java NIO handles this reasonably well with the java.nio.file.attribute package[2] in my opinion. (Not sure how easy it would be to port the concepts of that to Go though.) IANA has a registry of OS-specific facts (i.e. file attributes) and OS-specific file types[3] – this is for use of FTP MLST and MLSD commands[4] but the registry is rather empty because that RFC doesn't appear to have got much adoption. It is a good idea though. [1] There is a standard list of file types most platforms support – regular file, directory, link – but there are lots of special file types specific to various platforms (e.g. named pipes, UNIX domain sockets, BSD whiteouts, NTFS junctions), plus some filesystems have different subtypes of regular files or directories. (For example, on IBM z/OS, a "regular file" could be a UNIX file, a VSAM dataset, or a non-VSAM dataset, and the later two both have several subtypes; similarly, z/OS has UNIX directories, but PDS(E) could also be viewed as a non-UNIX type of directory.) [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/nio/file/attribute/package-summary.html https://docs.oracle.com/en/java/javase/14/docs/api/java.base... [3] https://www.iana.org/assignments/os-specific-parameters/os-specific-parameters.xhtml https://www.iana.org/assignments/os-specific-parameters/os-s... [4] https://tools.ietf.org/html/rfc3659 https://tools.ietf.org/html/rfc3659

heinrichhartman 6y ago

Calling stat on all the files is just really expensive if your directly is large.

networkimprov 6y ago
See the Reddit for an alternative to FileInfo. https://www.reddit.com/r/golang/comments/hv976o/qa_iofs_draft_design/ https://www.reddit.com/r/golang/comments/hv976o/qa_iofs_draf...
tptacek 6y ago
FileInfo is an interface, isn't it? You could populate fields other than "name" lazily, right?
- TheDong 6y ago
  You can't because the interface doesn't allow any errors. Lazily populating data is usually fallible, and the interface's methods are all infallible.
  - tptacek 6y ago
    OK, I'm convinced. Not a great interface, should just return an iterator.

skissane 6y ago

Every filesystem ever has the concept of file attributes. The problem is the exact details of what file attributes are supported vary widely from system to system. The best approach is to support a subset which is reasonably common across platforms – file type[1], modification timestamps, file size in bytes, etc – and an extension mechanism to enable platform-specific attributes. Java NIO handles this reasonably well with the java.nio.file.attribute package[2] in my opinion. (Not sure how easy it would be to port the concepts of that to Go though.) IANA has a registry of OS-specific facts (i.e. file attributes) and OS-specific file types[3] – this is for use of FTP MLST and MLSD commands[4] but the registry is rather empty because that RFC doesn't appear to have got much adoption. It is a good idea though. [1] There is a standard list of file types most platforms support – regular file, directory, link – but there are lots of special file types specific to various platforms (e.g. named pipes, UNIX domain sockets, BSD whiteouts, NTFS junctions), plus some filesystems have different subtypes of regular files or directories. (For example, on IBM z/OS, a "regular file" could be a UNIX file, a VSAM dataset, or a non-VSAM dataset, and the later two both have several subtypes; similarly, z/OS has UNIX directories, but PDS(E) could also be viewed as a non-UNIX type of directory.) [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/nio/file/attribute/package-summary.html https://docs.oracle.com/en/java/javase/14/docs/api/java.base... [3] https://www.iana.org/assignments/os-specific-parameters/os-specific-parameters.xhtml https://www.iana.org/assignments/os-specific-parameters/os-s... [4] https://tools.ietf.org/html/rfc3659 https://tools.ietf.org/html/rfc3659