From b88aa1929ef1b67801c0ea268bfd55f1edc1c522 Mon Sep 17 00:00:00 2001 From: Vitaliy Filippov Date: Mon, 17 Apr 2023 12:31:59 +0300 Subject: [PATCH] Do not crash when handling files of exactly maximum allowed size Test case: 1) Mount geesefs with --part-sizes 5 2) Reproduce the bug with the following bash script: ``` perl -e 'open FD, ">test-will-die"; sleep 20' & dd if=/dev/zero of=test-will-die oflag=direct bs=1M seek=0 count=200 dd if=/dev/zero of=test-will-die oflag=direct bs=1M seek=49999 count=1 sleep 20 ``` I.e. to reproduce the bug, you should have the last write to an inode end at maximum possible file offset, it should also have more modified data than just the last part, and there should be an open file descriptor for that file. --- internal/file.go | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/internal/file.go b/internal/file.go index 8160237b..ba7a80f3 100644 --- a/internal/file.go +++ b/internal/file.go @@ -64,6 +64,10 @@ func (fs *Goofys) partNum(offset uint64) uint64 { start += s.PartSize * s.PartCount n += s.PartCount } + if offset == start { + // Sometimes we use partNum() to calculate total part count from end offset - allow it + return n + } panic(fmt.Sprintf( "Offset too large: %v, max supported file size with current part size configuration is %v", offset, start,