Re: [PATCH 1/4] common: Fix file leak in _get_max_file_size

[Zorro Lang <zlang@redhat.com>]

On Thu, Sep 22, 2022 at 08:31:23PM -0700, Eric Biggers wrote:
> On Thu, Sep 22, 2022 at 03:48:19PM +0200, Pavel Reichl wrote:
> > This is obviously mostly problematic for FS lacking support for sparse
> > files.
> > 
> > Signed-off-by: Pavel Reichl <preichl@redhat.com>
> > ---
> >  common/rc         | 1 +
> >  tests/generic/692 | 0
> >  2 files changed, 1 insertion(+)
> >  mode change 100644 => 100755 tests/generic/692
> > 
> > diff --git a/common/rc b/common/rc
> > index 228fcb37..c9078649 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -4637,6 +4637,7 @@ _get_max_file_size()
> >  			l=$m
> >  		fi
> >  	done
> > +	rm -f $testfile
> >  	echo $l
> >  }
> 
> Removing the file is fine, but I didn't have filesystems that lack support for
> sparse files in mind when I wrote this function.  Maybe it should look at $FSTYP
> first, and only use the generic algorithm as a fallback for unhandled types?

That might be good idea. The current algorithm takes too long time for fs which
doesn't support sparse file.

Anyway, this $testfile should be removed. If Pavel would like to change this
function likes:

_get_max_file_size()
{
	case $FSTYP:
	exfat)
		# calculate the max file size of exfat according to blocksize, then
		echo $max_file_size_of_exfat
		;;
	# Add ext* if extN forks think it's better
	*)
		# By default, do the algorithm this function does originally
		;;
	esac
}

he can split this part as a separated patch, then let's review it. Or we can
have this patch at first, then let Eric change it when he'd like to do that.

Thanks,
Zorro

> 
> - Eric
>