FileManager: Implement contentsEqual(atPath:andPath:) #1510
Conversation
spevans
commented
Apr 8, 2018
spevans
commented
- Requires some more tests, especially for comparing directories.
|
@swift-ci please test |
Foundation/FileManager.swift
Outdated
| return false | ||
| } | ||
| } | ||
| return path1entries.isEmpty |
There was a problem hiding this comment.
I'd expect this to recurse for each item in the two directories. If the contents of 'A/C' doesn't match 'B/C', then this is supposed to fail.
Foundation/FileManager.swift
Outdated
| } | ||
|
|
||
| private func _compareSymlinks(withFileSystemRepresentation file1Rep: UnsafePointer<Int8>, andFileSystemRepresentation file2Rep: UnsafePointer<Int8>, size: Int64) -> Bool { | ||
| let bufSize = Int(size) + 1 |
There was a problem hiding this comment.
On Darwin at least, readlink does not append a NUL byte, so the +1 isn't strictly necessary.
Foundation/FileManager.swift
Outdated
| return false | ||
| } | ||
|
|
||
| if file1Type == S_IFCHR { |
There was a problem hiding this comment.
The same could be done here for S_IFBLK, no?
TestFoundation/TestFileManager.swift
Outdated
| XCTAssertFalse(fm.contentsEqual(atPath: symlink, andPath: testFile1URL.path)) | ||
| XCTAssertTrue(fm.contentsEqual(atPath: testDir1.path, andPath: testDir1.path)) | ||
| XCTAssertTrue(fm.contentsEqual(atPath: testDir2.path, andPath: testDir3.path)) | ||
| XCTAssertFalse(fm.contentsEqual(atPath: testDir1.path, andPath: testDir2.path)) |
There was a problem hiding this comment.
A test case that verifies recursive (in)equality is needed.
Foundation/FileManager.swift
Outdated
|
|
||
|
|
||
| private func _compareFiles(withFileSystemRepresentation file1Rep: UnsafePointer<Int8>, andFileSystemRepresentation file2Rep: UnsafePointer<Int8>, size: Int64) -> Bool { | ||
| let bufSize = min(size, 1024 * 1024) |
There was a problem hiding this comment.
It might be worth using st_blksize to pick an optimal block size. 1 MB (*2) seems like a rather large allocation.
There was a problem hiding this comment.
Im not sure how to relate it to block size, given there are only a few fixed block sizes. How does Darwin's Foundation decide on the buffer size to use?
There was a problem hiding this comment.
st_blksize is documented as "The optimal I/O block size for the file". I've taken that to mean that, especially if we're not reading the entire contents of the file into a single buffer (a la NSData), that this value is the system-declared preferred buffer size for I/O operations. I won't link directly to any here, but various implementations of 'cat' agree (including Darwin's).
Darwin's implementation of this method is fairly old and happens not to use this value—opting for a constant 8K size instead—though it should probably should.
There was a problem hiding this comment.
Ah right, I mis-read this as using some multiple of st_blksize rather than the value directly.
- For block devices, compare the major/minor to match character devices. - When comparing directory contents, compare the contents of each item in the directories.
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
Great, thanks @spevans! |
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
|
@swift-ci please test and merge |
