Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rename and rework File::Stat as File::Info #5584
Instead of always evaluating and copying to populate a generic struct with lots of data —which misses information btw, such as the creation time for the most obvious one— we could keep the simple wrapper over C structs.
If all I need is accessing the mtime for thousands of files, I'd like to avoid copying data for each and every file, or just checking over and over if it's a file, symlink or something else (pointless).
@ysbaddaden Information has been intentionally left out to make it portable.
I'll benchmark old stat vs new stat but i'm not sure that a bit of bit twiddling is going to make much difference when put next to the price of a syscall, and making it wrap
Benchmarks say it doesn't matter much. I'd definitely say it's not worth optimizing for a while.
I actually learned in this PR that
I believe Ruby started with "works only in unix" and eventually had to keep all those cryptic, unix-specific names. Go for example doesn't do this, it provides a clear interface to the computer without using ancient strange names. I think we should do the same, even if it means a bigger barrier to those coming from Ruby.
referenced this pull request
Jan 18, 2018
I'm sorry I'll feel grumpy, but I still have goosebumps, and no explanation for many (unwelcomed) changes:
stat naming to
info? it's still an abbreviation and doesn't tell any better.
Why decode & copy everything (check each file type, decode/copy permissions, generate Time instances) instead of using a wrapper for on-demand generation? Sure
File::Stat would be a mere delegation struct for the underlying POSIX vs Windows implementations, mostly to hold documentation, but the optimizer will inline calls, or we can just flag them with
Having to type
.stat.directory? can feel minor, but that's still an unwelcomed hick; forward calls from the struct to the enum, please.
- ctime & atime are still missing (!)
Looks good! Thanks for adapting
I just wish there was type delegators on
File::Info itself. Introducing a
.type really feels artificial. It can be useful, but most of the time —and actually every single use we have for— it is
file.info.type.xxx? when it could be a mere
file.info.x? (or even
Apr 14, 2018
Given the following files:
With the stdlib at master we currently have:
a = File.new("./a.txt") a_copy = File.new("./a.txt")
How to check if a1 and a1_copy refer to the same file?
a == a_copy # => false a.info == a_copy.info # => true
Ok, but how that works with b?
b = File.new("./b.txt") a.info == b.info # => true
How can I know that a and b are different files?
File.info?(a.path, follow_symlinks: false) == File.info?(a_copy.path, follow_symlinks: false) # => true File.info?(a.path, follow_symlinks: false) == File.info?(b.path, follow_symlinks: false) # => false
Ok, but what about if I use only the path of the
a_diff = File.new("a.txt") a.path # => "./a.txt" a_diff.path # => "a.txt"
You can use
File.expand_path(a.path) # => /full/path/to/a.txt File.expand_path(a_diff.path) # => /full/path/to/a.txt
So, what about?
That would make simpler all of the above scenarios with
They are the same file. The whole premise for that question is wrong on posix. The confusing part here is actually storing
You can unlink a path from the filesystem while it is open in a program just fine. And any open programs will keep the inode around in the filesystem, and the file will continue to use up disk space until the program is closed. Then
Path equality and file equality are entirely different things, and are pretty much entirely unrelated and unreliable until the moment in time you call
Ok, so @RX14 you say to only
I'm fine with that also.
Although the premise for the question might seems wrong, but I think it depends on the use case. If someone wants to deal with lower level of file system some api are not the best. But is not the more common use case and it is still doable.
Mixing symlinks with hard links to detect file identify is IMHO introducing confusing behavior. Furthermore, detecting hard links is quite specific, and not widely used. We don't need a abstraction for this, hence why I'm proposing to keep exposing inodes on POSIX systems and be done with it.
Simple, does the job, no confusing behavior, and allows finer grained detection. All it needs is to expose a value that we already have.
@bcardiff having a
@ysbaddaden the reason why I want to only expose equality only is because your examples are wrong! You must compare device and inode to be sure they're the same file. If even you get this wrong, then surely thats a fantastic reason to expose this nicely instead of just expose the platform-specific inode (which won't even exist on windows).