aboutsummaryrefslogtreecommitdiff
path: root/src/flatfile.cpp
AgeCommit message (Collapse)Author
2022-04-21Disallow more unsafe string->path conversions allowed by path append operatorsRyan Ofsky
Add more fs::path operator/ and operator+ overloads to prevent unsafe string->path conversions on Windows that would cause strings to be decoded according to the current Windows locale & code page instead of the correct string encoding. Update application code to deal with loss of implicit string->path conversions by calling fs::u8path or fs::PathFromString explicitly, or by just changing variable types from std::string to fs::path to avoid conversions altoghther, or make them happen earlier. In all cases, there's no change in behavior either (1) because strings only contained ASCII characters and would be decoded the same regardless of what encoding was used, or (2) because of the 1:1 mapping between paths and strings using the PathToString and PathFromString functions. Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
2021-12-30scripted-diff: Bump copyright headersHennadii Stepanov
-BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT- Commits of previous years: * 2020: fa0074e2d82928016a43ca408717154a1c70a4db * 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
2021-10-05refactor: Block unsafe fs::path std::string conversion callsRussell Yanofsky
There is no change in behavior. This just helps prepare for the transition from boost::filesystem to std::filesystem by avoiding calls to methods which will be unsafe after the transaction to std::filesystem to due lack of a boost::filesystem::path::imbue equivalent and inability to set a predictable locale. Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com> Co-authored-by: Kiminuo <kiminuo@protonmail.com> Co-authored-by: MarcoFalke <falke.marco@gmail.com>
2021-02-10log: Move "Pre-allocating up to position 0x[...] in [...].dat" log message ↵practicalswift
to debug category
2020-08-25Fix possible data race when committing block filesEvan Klitzke
It was recently pointed out to me that calling fsync() or fdatasync() on a new file is not sufficient to ensure it's persisted to disk, a the existence of the file itself is stored in the directory inode. This means that ensuring that a new file is actually committed also requires an fsync() on the parent directory. This change ensures that we call fsync() on the blocks directory after committing new block files.
2019-02-22Style cleanup.Jim Posen
2019-02-22scripted-diff: Rename CBlockDiskPos to FlatFilePos.Jim Posen
-BEGIN VERIFY SCRIPT- sed -i 's/CDiskBlockPos/FlatFilePos/g' $(git ls-files 'src/*.h' 'src/*.cpp') -END VERIFY SCRIPT-
2019-02-22Move CDiskBlockPos from chain to flatfile.Jim Posen
2019-02-22validation: Refactor file flush logic into FlatFileSeq.Jim Posen
2019-02-22validation: Refactor block file pre-allocation into FlatFileSeq.Jim Posen
2019-02-22validation: Refactor OpenDiskFile into method on FlatFileSeq.Jim Posen
2019-02-22validation: Extract basic block file logic into FlatFileSeq class.Jim Posen