Thanks to everyone who pointed me in the right direction on this problem, I
have been able to find a work around that allows me to push to an archive on a
network file share.
After some digging, I discovered the root of the problem. Briefly, Darcs uses
the standard library System.Directory to perform file manipulations. This
library make use of compiler pragmas to conditionally compile either the
Windows or Linux specific functions based on the host operating system.
This approach assumes that when your operating system is a Linux variant, all
your mounted volumes will natively support POSIX. When you have mounted CIFS
volumes, this will result in errors when calling those library functions to
create, rename, copy and delete files or folders! Given the flexibility of
the Linux operating system, A more versatile implementation for
System.Directory might be able to detect the file system of each volume at
runtime and choose the appropriate functions to call. But I digress...
To workaround the inability to push to a CIFS volume in darcs, I modified the
workaround.hs module to shell out to the OS's rename function rather than using
the Haskell library's rename function. Specifically:
I added the following code after the #else near line 80:
renameFile :: FilePath -> FilePath -> IO ()
renameFile old new = do
ecode <- System.Cmd.rawSystem "mv" [old,new]
case ecode of
ExitSuccess -> return ()
ExitFailure n -> putStrLn ("renameFile failed with exit code" ++ show
n)
which ensures that when the operating system is not WIN32, that renaming of
files will be performed by the OS shell. I then added the System.Cmd module to
the list of imports by inserting the following code near line 21
import qualified System.Cmd(rawSystem)
after a recompile I could push to a CIFS volume, for example:
sudo darcs push /mnt/cifsvol
this is an obvious hack, and does not address the inability to put to a CIFS
share (put depends upon copyFile and would need to be hacked to shell-out as
well). Archives on the CIFS share have to be created by navigating to that
folder and initializing.
Shelling out is clearly a poor long term solution; a longer term solution would
ideally introduce into the Haskell System.Directory library the ability to
apply the correct functions transparently in accordance with the file system of
the volume.
Cheers
-Darrell Lewis-Sandy
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
