[darcs-users] Re: darcs - Problem with MacOS X HFS+ File System
droundy at abridgegame.org
Thu Mar 3 13:26:40 UTC 2005
On Thu, Mar 03, 2005 at 12:04:12PM +0100, Markus Hanauska wrote:
> And some more input from me :)
> Sorry, but we need this bug fixed ASAP.
> I found a very interesting page:
> The interesting part is the following:
> HFS+ lacks support in the volume format for hard links, a standard
> feature of UFS. Initially, the attempted creation of a link to a file
> would yield a "not supported" error. We had discussed some "80%"
> solutions, such as creating symbolic links instead, but the semantics
> of symbolic links are significantly different. For troubleshooting
> reasons it is preferable to fail at link creation time than at some
> later time due to problems related to these semantic differences. The
> problem is that there is a significant amount of software which breaks
> if hard link creation fails, and some of that software needs to be
> redesigned if hard links cannot be used. In order to accommodate this
> software, we now emulate hard links by creating a "kernel-level"
> symbolic link which is visible only to and interpreted by the HFS+ file
> system. This was necessary due to the lack of support in the volume
> format. The resulting behavior is very similar to that of hard links
> when viewed from above the kernel, though they are relatively
> inefficient in comparison.
> So maybe the implementation is pretty broken.
> This leaves the question why darcs creates hard links in the first
> place, in case it does?
Okay, I think I may have an idea what's happening here, although I haven't
verified it. In order to atomically modify files, darcs uses the haskell
(standard library) function "renameFile", which is supposed to atomically
overwrite the target file, if it already exists (so that in case of
crash/power outage it is guaranteed that either the old or the new version
of that file exists).
On windows, we can't do this, as there isn't an atomic rename operation, so
we just need to hope for the best. My guess is that the ghc implementation
perhaps implements renameFile "a" "b" as something equivalent to
ln a b
which according to your tests would render the file b unopenable by xcode.
(And also is guaranteed to work on any POSIX filesystem, so it's not
unreasonable on a system that claims to be POSIX.)
This ought to be straightforward to work around--we already have an
autoconf test that checks whether renameFile fails if the target file
already exists (for windows) and uses an alternate version if that is the
case. We just need to figure out whether we're running on MacOS, and if
that is the case use an alternate method--perhaps the same as we do in
windows, just delete the target file first and hope the power doesn't go
It also would be good (if this analysis is correct) to point this out to
the ghc folks, so they could fix their implementation of renameFile.
Are there any mac developers here who could track this down? If not, I'll
try to get to it tomorrow.
> On 03. Mrz 2005, at 11:15 Uhr, Markus Hanauska wrote:
> >Maybe I was wrong, maybe it is link related.
> >Try this:
> >touch file1.c
> >ln file1.c file2.c
> >rm file2.c
> >Try to edit file1.c with XCode, Subethaedit or Smultron. It won't
> >work with any of these editors. You can open and edit, but you can't
> >save your changes.
> >Also nice, try this one:
> >touch file1.c
> >ln file1.c file2.c
> >rm file1.c
> >Now try to edit file2.c. You can't even open it with XCode!
> >I'd like to create a darcs version, that does for sure not create any
> >links, but I already fail to compile tho unmodified version from
> >source, it complains about missing symbols when linking. Aside from
> >this I don't understand more of Haskell than some basic semantics,
> >making changes to the source code a bit problematic.
More information about the darcs-users