Gerk's dashboard

Gerk replied on September 03, 2009 16:35 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

FWIW you can still only set the default umask on the windows client, the OSX one doesn't have this option.

Gerk replied on July 20, 2009 16:21 to the problem "Watch while Expandrive destroys my data in this video." in ExpanDrive:

Ahh I see. Is there an interactive forum of any sort or just direct with support?

Gerk replied on July 20, 2009 16:14 to the problem "Watch while Expandrive destroys my data in this video." in ExpanDrive:

This problem is marked as solved?? What is the resolution?

Gerk replied on July 20, 2009 16:13 to the problem "Watch while Expandrive destroys my data in this video." in ExpanDrive:

Eeek this is pretty scary. Looks like there are still some permissions gremlins in this package.

Gerk replied on July 20, 2009 16:07 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Has this issue been resolved with the 2.x release?

Gerk replied on February 22, 2009 04:18 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Have the ExpanDrive folks given up on this one?

Gerk replied on February 13, 2009 05:17 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

I'd like to add also that in the case of an existing file the "new" file (i.e. the file that is there after you edit and save) should have the same permissions as the previous version did.

Gerk replied on February 04, 2009 18:51 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Hi Gordon

Yes I see this exact same behavior as well, any file I edit the permissions get stomped which also makes it unusable for me.

Gerk replied on January 24, 2009 20:43 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Our intended behaviour for ExpanDrive was to honor the local umask, not the remote one, since it is supposed to present a remote filesystem as if it were connected locally. The test cases you showed indicate that it's not doing that, at present, which---as I see it---is something we need to work around. I would certainly agree that we should honor either the local umask or the remote one! :)

My tests show that it is in fact honoring my local umask and not the remote one, I think you still have things backwards here. If you folks are taking the opinion of treating the mounted filesystem as a if it were a local filesystem (which it most obviously is not) then it's the wrong approach without a doubt. it is a remote filesystem and the files and folders created on it must be compatible with the way the remote server is setup, first and foremost. Being able to mount it locally is nothing more than a convenience and shouldn't be treated as the primary usage for the filesystem.

At this point I think I'm just going to toss my hands into the air and walk away and go find myself another SFTP client. Sorry if it sounds abrupt, but Expandrive's first and foremost function is as an SFTP client ... and as a client it should be honoring the permissions as set by the server, not setting it's own policies and breaking everything it touches on the server.

Gerk replied on January 24, 2009 20:32 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

I feel strongly that it should honor the remote umask, as it did up until 1.3.3 was released ... that's the whole point of having a umask set on the remote server, so that the files created on that server have the default permissions that the server assigns. Honoring the local umask is not helpful as it's not a local filesystem (even though it's mounted locally).

To me this is a bug, as again, it worked as expected (at least as I expected) until 1.3.3 came out when there was a behavioral change. All of the other popular SFTP clients honor the remote server's umask.

If it doesn't honor the remote umask it's going to cause grief for a lot of users (like me) who need things set with specific permissions on a per-server basis. Having to adjust your local umask in order to accomplish that is not viable (what happens when you need to connect to 2 different servers at one time that need different default permissions?)

Also when you do need things like a umask of 0002 on a remote server you shouldn't have to compromise your local umask by enforcing full group access to all of your files on your local workstation to accomplish this!

Gerk replied on January 24, 2009 19:40 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

"I traced the calls passed from MacFUSE into the ExpanDrive filesystem driver, and it is in fact giving ExpanDrive the "correct" permission bits, relative to the local filesystem's umask. However, with my test setup (OpenSSH_5.1p1) these are getting clobbered by the SFTP server during file and directory creation, presumably because it is applying its own (remote) umask to the mode word we send."

This is the exact behaviour I'm LOOKING for! You have it opposite to what I've reported here. All of the other SFTP clients honor the remote umask when you make a new file -- which is correct behaviour. Expandrive is using the local umask and ignoring the umask set on the server.

*sigh*

You might want to re-read all of the above posts. If I understand what you are saying then it means that Expandrive is currently working correctly for you but not for me. Please test with the examples I've given in this thread -- try with a remote umask of 0002 (on your server). This is a very common setup (to give group access to new files by default) and the exact issue I'm having and can reproduce the behaviour on multiple servers/different OSes.

Gerk replied on January 23, 2009 21:33 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

you said: "My apologies for the delay in responding. I must admit, I'm not sure why there should be any difference between version 1.3.2 of ExpanDrive and later versions"

1.3.3 introduced MacFUSE 2.0 usage.

Gerk replied on January 23, 2009 20:55 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Yes I also can pretty much confirm this is a MacFUSE issue as I stated earlier in this thread. I tested with sshfs.app and had the same results as expandrive. MacFUSE 1.7 worked as expected (reading and setting the umask properly), MacFUSE 2.0 did not work properly. This happened with both Expandrive and sshfs.app (both of which use MacFUSE).

I was hoping that you guys, since you use MacFUSE for your core could cofirm this and take it up with the MacFUSE folks ...

The problem is that us end-users can't see the actual call being made, so it's not much use for us to file bug reports with the MacFUSE folks ... I know that at command line at least there's a way to pass the umask, but Expandrive seems to use other 3rd party python stuff, so who knows what's going on under the hood :)

Gerk replied on January 23, 2009 20:29 to the problem "permission or naming error" in ExpanDrive:

Actually it's probably all tied back to this issue:

http://getsatisfaction.com/expandrive...

Word and Dreamweaver both do try to change the default program to open the file with when you save them.

Gerk replied on January 23, 2009 20:26 to the problem "permission or naming error" in ExpanDrive:

This is likely the same issue I'm having here:

http://getsatisfaction.com/expandrive...

I suspect this is due to Word (and in my case DreamWeaver) trying to set information in resource forks on open/save, which it can't do with Expandrive it seems.

Gerk replied on January 23, 2009 20:18 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Bump ... ok this one is getting pretty frustrating guys, no responses at all from the Expandrive folks in 17 days.

This problem is causing me a ton of chaos here, having to manually fix every single file that Expandrive touches (and breaks). Guess it's time to move on to another app if this can't get resolved, sigh.

Gerk replied on January 15, 2009 20:53 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

bump ... any news on this one Jeff? Haven't heard anything back from you since you asked about trying it in another sftp client 9 days ago ...

Gerk replied on January 13, 2009 22:26 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

I regressed with today's release, 1.3.4 .. still has this issue.

-rw-r--r-- 1 mark 500 0B 13 Jan 17:24 testexpandriveWS-1.3.4

Gerk replied on January 13, 2009 22:25 to the problem "Expandrive 1.3.3 crashes on reconnection to SFTP server." in ExpanDrive:

That link downloaded 1.3.3 for me (maybe cache didn't catch up?) ... when I manually checked for update it gave me 1.3.4

Gerk replied on January 09, 2009 23:09 to the problem "Default permissions differences on SFTP mounts (inheritance/umask?)" in ExpanDrive:

Just to note for regression purposes, the problem still exists with Expandrive 1.3.4b2

-rw-r--r-- 1 gerk gerk 0 Jan 9 18:07 testexpandriveWS-1.3.4b2