bug#6397: 24.0.50; `make-directory' return value

bug#6397: 24.0.50; `make-directory' return value

[Drew Adams]

The doc for `make-directory' doesn't mention its return value, and the
code doesn't seem to do anything special about it.
 
I think it should return non-nil (e.g. the directory name) if the
creation succeeds and nil if it fails without error.  And that should be
documented.  Or if it always raises an error when it does not create a
directory, that's OK too, but that should then be documented.
 
Yes, you can always determine whether it succeeded by checking
`file-accessible-directory-p' or `file-exists-p' afterward (and
beforehand, and comparing), but reasonable creation functions let you
know whether they succeed.
 
 
 
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-06-07 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/xpm/include'
 

bug#6397: 24.0.50; `make-directory' return value

[Juri Linkov]

> The doc for `make-directory' doesn't mention its return value, and the
> code doesn't seem to do anything special about it.

There is also a related bug#6363.

> I think it should return non-nil (e.g. the directory name) if the
> creation succeeds and nil if it fails without error.  And that should be
> documented.  Or if it always raises an error when it does not create a
> directory, that's OK too, but that should then be documented.

What should it return when the creation of some parents succeeds,
and fails for the rest?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6397: 24.0.50; `make-directory' return value

[Drew Adams]

> > The doc for `make-directory' doesn't mention its return 
> > value, and the code doesn't seem to do anything special
> > about it.
> 
> There is also a related bug#6363.
>
> > I think it should return non-nil (e.g. the directory name) if the
> > creation succeeds and nil if it fails without error.  And 
> > should be documented.  Or if it always raises an error when it
> > does not create a directory, that's OK too, but that should then
> > be documented.
> 
> What should it return when the creation of some parents succeeds,
> and fails for the rest?

Why do we let that happen? That seems like a bug. Is there some use case for
that? If not, can we fix it, to make the creation all-or-nothing (e.g. delete
any created unless all are)?

If the aim of the function is to create directory /a/lot/of/parents/foo, then
what sense does it make to create only some of the parents?

bug#6397: 24.0.50; `make-directory' return value

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> I think it should return non-nil (e.g. the directory name) if the
> creation succeeds and nil if it fails without error.  And that should be
> documented.  Or if it always raises an error when it does not create a
> directory, that's OK too, but that should then be documented.

So you want the doc string to say that it will raise an error if there's
an error?  Ok, I've now done that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#6397: 24.0.50; `make-directory' return value

[Drew Adams]

> So you want the doc string to say that it will raise an error 
> if there's an error?  Ok, I've now done that.

Thanks.

But it sounds like there might still be a bug if the creation of the directory
and any missing parents is not an atomic transaction.  See the rest of the
thread.

bug#6397: 24.0.50; `make-directory' return value

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> But it sounds like there might still be a bug if the creation of the directory
> and any missing parents is not an atomic transaction.  See the rest of the
> thread.

I don't think there's anything that can be done about that.  Creating a
full path isn't atomic, and deleting the directories we've already made
is bad, too.  Some other process may have wanted the directories at the
same time, and would bug out if we started deleting them.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#6397: 24.0.50; `make-directory' return value

[Drew Adams]

> I don't think there's anything that can be done about that.  
> Creating a full path isn't atomic,

We know we're trying to create a hierachy of directories, and we know that it
must be an all-or-nothing transaction.  Why can't we make this atomic in this
particular case?

There's nothing magic about transactions.  In this case the rollback would be
simple: delete any directories created if for some reason we cannot create them
all.

> and deleting the directories we've already made
> is bad, too.

Why?  That's a normal rollback for this.  There's not a lot going on here: just
directory creation.

> Some other process may have wanted the directories at the
> same time, and would bug out if we started deleting them.

I suppose that's a legitimate point in the abstract, but highly unlikely in
practice.  And there is probably some way (file attributes? permissions?) of
making any created directories invisible/inaccessible during the transaction.

I don't see why Emacs Dev wouldn't try to fix this correctly.  Unless I'm
missing something.

bug#6397: 24.0.50; `make-directory' return value

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> I suppose that's a legitimate point in the abstract, but highly unlikely in
> practice.  And there is probably some way (file attributes? permissions?) of
> making any created directories invisible/inaccessible during the transaction.

Nope.  There isn't.

You often see this sort of problem in web server caches, where you have
a gazillion processes all trying to create variants on the same
directory structures.  This may fail because two processes tries to
create /var/tmp/cache/foo/bar/zot at the same time, for instance.
Trying to unwind this in a general fashion is impossible, and must be
left to a higher level to determine what to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/