chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Two minor file-related patches


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Two minor file-related patches
Date: Mon, 25 Sep 2017 20:53:40 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Sep 15, 2017 at 10:07:18PM +1200, Evan Hanson wrote:
> Hi hackers,
> 
> Here are two small patches. The first just removes a helper procedure
> that I think is no longer necessary, `##sys#platform-fixup-pathname`,
> which only affects MinGW and doesn't seem to be needed anymore (see the
> commit message for details about that).

It seems that this patch is necessary after all.  I tested with the
"regular" MingW with MSYS (for some reason csi just hangs on MSYS2...)
and I see the following:

#;1> (use (chicken file))
#;2> (directory-exists? "c:/cygwin")
"c:/cygwin"
#;3> (directory-exists? "c:/cygwin/")
#f

In the old implementation it returned the path in both calls.  So, as
you can see it seems this functionality is required after all.

I do agree that fixup-pathname should probably remove all trailing
path separators rather than just the last one; that's just broken.

> The second patch fixes a TOCTTOU
> problem with `delete-file*`, brings its return value in line with the
> documentation, and also speeds it up by about 2x judging by my testing.

This also changes the semantics drastically.  When using delete-file*,
you generally do so because you're not interested if it doesn't exist;
you're just interested in the end effect, that the file no longer exists
after having called the procedure.

However, if the file *can't* be deleted for whatever reason, the original
implementation would raise an exception, whereas the version after this
patch will merrily return #f and continue the program.

In other words, this will hide *all* errors, which can result in the program
to fail specatularly because its preconditions don't hold.  I believe
we need to check errno in case the return value is nonzero, and only
ignore ENOENT, or am I missing some other return codes?  I don't know
what to do with EAGAIN/EWOULDBLOCK: POSIX doesn't mention these codes
in remove(), but maybe some implementations could return them anyway?

This page seems to imply that unlink() (and by extension remove()) may
return EAGAIN:
https://www.kernel.org/doc/htmldocs/filesystems/API-vfs-unlink.html

Cheers,
Peter

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]