Matt Moskwa's dashboard

Matt Moskwa replied on August 18, 2008 14:41 to the question ".DS_Store problems" in ExpanDrive:

I'm not sure what's going on; ExpanDrive already does this. Are you sure the .DS_Store file weren't present already, before ExpanDrive touched the server?

Matt Moskwa replied on July 31, 2008 20:57 to the problem "Colons in "Drive Name"" in ExpanDrive:

Luke, we've fixed this. Expect it in our next update.

A comment on the discussion "Setting file upload permissions" in ExpanDrive:

Ah yes, pathfinder. We've been putting off fixing that. Today is a special day, though. We're going to install all of programs that have been causing sporadic problems and really hammering at them. We'll let you know if we find anything. I really hope we can get this fixed for you. It sounds really annoying. – Matt Moskwa, on July 31, 2008 18:41

A comment on the discussion "Setting file upload permissions" in ExpanDrive:

Does renaming files with ExpanDrive not work for you? I'm also still curious about the permissions issue. Are all files uploaded with mode 700, or just a specific file? – Matt Moskwa, on July 31, 2008 16:14

Matt Moskwa replied on July 31, 2008 15:44 to the discussion "Setting file upload permissions" in ExpanDrive:

Did you see the first reply in this thread, about BatChmod? I haven't tried it myself, but it's probably worth a spin to see if does what you suggest.

Matt Moskwa replied on July 31, 2008 15:18 to the discussion "Setting file upload permissions" in ExpanDrive:

Repi,
This is Finder's fault and unfortunately, we don't have a solution yet. Finder explicitly calls chmod 644 whenever a new file is created, so even if the initial permissions were correctly set to 664, they will be changed automatically. A fix is on our to-do list, but for now, you'll have to manually change file permissions in terminal if you need the file to be group-writable.

Astromac,
Does this happen for every file, or just a specific file or kind of file?

Matt Moskwa replied on July 28, 2008 22:37 to the question "Need to su or sudo!" in ExpanDrive:

OK, I'll look into the sftp-server thing. Thanks for the tip!

Matt Moskwa replied on July 28, 2008 16:19 to the question "Need to su or sudo!" in ExpanDrive:

I'm not entirely sure what the "SFTP server option" refers to, but I think that's the same as what I suggested above. It's just logging into the server using the substitute username, which is effectively the same thing as using sudo.

Matt Moskwa replied on July 23, 2008 17:07 to the problem "Saving an Excel File w/ 1.2.9" in ExpanDrive:

Thanks for all the info. I'll look into this. It's probably a really easy fix. Every program, and apparently every version of every program, saves files using a different chain of events, so these kinds of bugs crop up from time to time. We can't test every version every time, obviously, so this is bound to happen. I'm sorry this time it was software you all use regularly.

Matt Moskwa replied on July 22, 2008 23:02 to the problem "Saving an Excel File w/ 1.2.9" in ExpanDrive:

PDXMan,
Is this also with Office 2004 and password protection on the files?

Matt Moskwa replied on July 22, 2008 18:11 to the problem "MacFUSE force ejects volumes if userland process is unresponsive" in ExpanDrive:

If you eject from the drive manager (Command-E or right-click->"eject"), ExpanDrive does what you're asking. I suppose we should be be more forthright about the fact that "eject" is actually force-eject.

MacFuse has a daemon timeout that kicks in after 60 seconds with no response from userland, but it doesn't always properly unmount. We can't disable it entirely, or else your whole system would become unresponsive in the case where MacFuse is starved for data. Perhaps there is a bug with ExpanDrive in that it doesn't obey the MacFuse force-eject, and we'll look into that. For the time being, the manual force-eject from the drive manager should suffice.

Matt Moskwa replied on July 21, 2008 20:15 to the problem "Saving an Excel File w/ 1.2.9" in ExpanDrive:

The password protection might have something to do with it, but you say they've always saved in version previous to 1.2.9, so I'm perplexed. I'm going to install Office 2004 soon and try this out. Is the password protection an Office feature, or something external? I've never used it before.

Matt Moskwa replied on July 21, 2008 18:45 to the problem "Saving an Excel File w/ 1.2.9" in ExpanDrive:

Is this a one-time bug, or does it happen every time you try to save the file? I only have Office 2008 to try at the moment, but I'm not seeing any problems.

Matt Moskwa replied on July 21, 2008 18:03 to the discussion "Setting file upload permissions" in ExpanDrive:

I would also expect the permissions to be 644. This is usually what Finder does. I'm very surprised that the x bit is set. What kind of file is it? Is there anything special about your server setup, like strange permissions or setgid bit on $HOME?

Matt Moskwa replied on July 18, 2008 15:17 to the problem "Incorrect space reported on connecting to Qnap NAS" in ExpanDrive:

sdh:
This is very odd indeed. Are you logging into ExpanDrive with the same credentials as ssh? If that is what is returned by running that python command, I can't imagine what the problem is. If this is a still a big deal for you, we might have to do some one-on-one debugging.

bill:
It's extremely curious that those two commands return different values. The first one is the more relevant one, but did you change directory to something other than $HOME to run that command? Do you have your directory structure set up strangely?

The two free space values you would get from those python structures are 110MB and ~6.6GB, respectively. Which one is ExpanDrive showing? Or is it another value entirely?

Matt Moskwa replied on July 15, 2008 15:21 to the problem "The magical reappearing folder trick" in ExpanDrive:

This is a known, but rare problem. In order to trick Finder into correct behavior, we have to pretend some folders on server have .DS_Store files. This naturally means any .DS_Store files in that folder before ExpanDrive got to it are going to cause problems. We don't create any .DS_Stores with ExpanDrive, so you must have transferred a local folder using some other client (SSHFS perhaps?).

We have three options for proceeding. One, we could leave it as is. Most people are fine with this because it means no .DS_Store files are created on server, but Finder displays correct behavior with folder views and copying entire folders. If you for some reason have .DS_Stores present on server, you'll to manually remove them. Two, we could have ExpanDrive delete an .DS_Store files it encounters during a directory listing. We don't really like this because we don't want to get into the business of modifying files we didn't explicitly create, but it would work. Three, we could provide the option to not do anything. .DS_Store files would persist on the server, but that won't cause any problems in and of itself. What works the best for you?

Matt Moskwa replied on July 09, 2008 13:30 to the question "I do not have sufficient access privileges to open folder" in ExpanDrive:

Infotexture:
Using those values from your May 14 post, I think we have a solution. We'll shortly release a nightly build for you to evaluate.

Matt Moskwa replied on July 02, 2008 20:02 to the problem "Incorrect space reported on connecting to Qnap NAS" in ExpanDrive:

We must not be able to run the command we want to run, os.statfs, or it's returning values we don't understand. Can you login over ssh and run it yourself, then tell us what you see? The entire command, from the command line, is:
%% python -c "import os; print os.statvfs('.')"

Also try:
%% python -c "import os; print os.statvfs(os.path.expanduser('~'))"

and see if it returns anything different.

Matt Moskwa replied on June 30, 2008 19:40 to the problem "Incorrect space reported on connecting to Qnap NAS" in ExpanDrive:

Does the df command work on your NAS? We currently run a python command,but we could configure ExpanDrive to attempt df as well, in which case we could return something like an accurate value for available space.

Matt Moskwa replied on June 27, 2008 18:51 to the question "Which version of MacFUSE is safe with ExpanDrive and Parallels?" in ExpanDrive:

ExpanDrive is currently compiled against MacFuse 1.3.1, and it won't work with later versions. We're currently waiting on the release of MacFuse 1.6.1, so we probably won't release a version that works with 1.5.1. Unless there is a compelling reason to use MacFuse 1.5.1 (we'll send you a patch if there is), just let ExpanDrive downgrade for you.