Hi Zeno,

On 2026-04-10T21:12:02+0200, Zeno Endemann wrote:
> Alejandro Colomar wrote on 10.04.26 19:47:
> > Hi Zeno,
> > 
> > On 2026-04-10T18:52:29+0200, Zeno Endemann wrote:
> > > Hello,
> > > 
> > > I noticed that the man page for truncate(2) does not list the error codes
> > > ENOSPC and EDQUOT, but I would think those should be potentially possible
> > > when actually expanding a file (may depend on file system?).
> > > 
> > > Similarly, fallocate(2) also does not list EDQUOT (ENOSPC is there however).
> > > Finally, posix_fallocate(3) has no EDQUOT as well, and EIO also seems to be
> > > missing for this one.
> > > 
> > > Or am I overlooking something?
> > 
> > Sounds plausible.  If you could either perform some experiments or show
> > the relevant kernel sources that make it possible, we could know for
> > sure.  If you find out it's possible, would you mind sending a patch?
> 
> I ran a quick test, on a FAT32 partition ftruncate can indeed return ENOSPC.

Thanks!  Would you send a patch?

> On most other file systems I suspect it will not, as most fs support files
> with unallocated space. Not sure there is a file system supporting quotas
> but not sparse files, I have never worked with quotas. Maybe someone else
> can pitch in there?
> 
> As a side note, I think it would be preferable if the allowed error codes
> would be agreed upon / specified regardless of whether there is an in-kernel
> file system which can currently actually return those,

What I'd like is to say "This system call may fail for the same reasons
as <this other>" (plus then a list of syscall-specific errors).  This
would simplify documentation of possible errors, while being much more
accurate.


Have a lovely day!
Alex

> since how things are
> implemented can change over time, and there is also FUSE - technically with
> my own FUSE file system I can make these functions return any arbitrary errno
> value, but a well-behaving FUSE implementation of course would restrict itself
> to such a specified "contract". Though I suppose this is likely not the right
> place to discuss this further ;)
> 
> Cheers,
> 
> 
> > 
> > 
> > Have a lovely day!
> > Alex
> > 
> > > 
> > > Thanks,
> > > Zeno Endemann
> > > 
> > > 
> > 
> 

-- 
<https://www.alejandro-colomar.es>