Mount Storage As a Webdav On OSX 5.8

Update April 21st: I Have managed to get to mount and to write files, however I can only copy one file at a time. after each file the wdfs process crashes. at this point I’m not investigating further

Don’t know what the deal thee problem lies with my reluctance to upgrade my OSX 5.8 to a newer cat version, but I just couldn’t mount directly using finder. I mean it technically did mount but it was impossible to access any files not for read nor write.

searching the net I did came up with an alternative code to mount webdav resources called wdfs. in spite the fact that it didn’t list any updates since 2007(!). I’ve decided to give it a try.

after an easy confgiure-make-make install I issued:

wdfs  /Volumes/box/ -o debug

and I could read my webdav, which was a major step forward.
writing to the webdav, however, seems to be a different story. I could upload a file using the web interface — and then append to it.

echo "1234" >> ./foo 

yielded the expected results as long as foo existed.
if the file didn’t exist I got the following errors on stderr (thanks to the -o debug flag off course!)

unique: 2, opcode: OPEN (14), nodeid: 11, insize: 48
## GET error: Could not read chunk size: connection was closed by server
   unique: 2, error: -2 (No such file or directory), outsize: 16
unique: 3, opcode: LOOKUP (1), nodeid: 8, insize: 44
Could not read chunk size: connection was closed by server

looking for the error in wdfs source code and some further debugging — it turns out that it comes from the wdfs_open() function.
below is an abbreviated version for clarity:

static int wdfs_open(const char *localpath, struct fuse_file_info *fi)

	struct open_file *file = g_new0(struct open_file, 1);
	file->modified = false;

	file->fh = get_filehandle();
		remotepath = get_remotepath(localpath);

	/* GET the data to the filehandle even if the file is opened O_WRONLY,
	 * because the opening application could use pwrite() or use O_APPEND
	 * and than the data needs to be present. */
	if (ne_get(session, remotepath, file->fh)) {
		fprintf(stderr, "## GET error: %s\n", ne_get_error(session));
		return -ENOENT;


It turns out that wdfs insists on issuing an HTTP GET even if we’re in the midst of creating the file.
not sure why the server reply with a

"Could not read chunk size: connection was closed by server"

but one thing for sure, if I just ignore the error as follows:

	if (ne_get(session, remotepath, file->fh)) {
		fprintf(stderr, "## GET (wdfs_open) error: %s\n", ne_get_error(session));

		/* Mcradle -> Patch don't return an error 
		return -ENOENT;

the file is created just fine, and I can issue a cp command, and verify that the data made it.
this brings a whole new meaning to the term monkey patching 🙂

Please be warned: your mileage may vary, as I’m not sure how legit is to ignore this error, and why is it there to begin with.

This entry was posted in "software enginerring", open source, OSX, workaround and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s