You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-dev@incubator.apache.org by Joakim Back <jo...@notitium.se> on 2007/08/24 07:55:17 UTC

Write-permissions under MacOSX

Hello!

I've been working with a virtual filesystem for a while, and so far it's 
been working great. Now the issue is to support the most common 
ftp-clients as to move away from the status as a novelty-feature.

The one client I'm having issues with currently is the native 
ftp-support in MacOSX (Finder?). The server transmits a user with write 
permissions, and while most folders are not write-permissible, there is 
an equivalent of an upload directory, the user Workspace folder at root.

The MacOSX native client disregards the unique folder permission and 
decides that all directories at the server is read only. Has anyone else 
had any experience with this? If I connect with the Transmit program, 
everything works as expected, and also under Windows native (Explorer?) 
and various clients.

Using MacOSX 10.3.9, Finder 10.3.2.

(To support MacOSX native client is important, as to be able to connect 
the FTP-server as a remote-drive for seamless integration.)

-- 
Best regards,

Joakim Back



Re: Write-permissions under MacOSX

Posted by Niklas Gustavsson <ni...@protocol7.com>.
That looks like a perfectly good listing, must be some serious problem 
with the client.

/niklas

Joakim Back wrote:
> I'm not sure how to further debug this issue, which is why I'm posting 
> already with little new information to provide.
> 
> Here's the list result (fixed-width formatting);
> 
> Windows cmd:
> 
> ftp> ls
> 200 Command PORT okay.
> 150 File status okay; about to open data connection.
> dr--------   1 ImageServer ImageServer            0 Aug 27 08:57 Folder A
> dr--------   1 ImageServer ImageServer            0 Aug 27 08:57 Folder B
> drw-------   1 ImageServer ImageServer            0 Aug 27 08:57 Workspace
> 226 Closing data connection.
> 
> Mac OS-X shell:
> 
> ftp> ls
> 229 Entering Passive Mode (|||3450|)
> 150 File status okay; about to open data connection.
> dr--------   1 ImageServer ImageServer            0 Aug 27 10:32 Folder A
> dr--------   1 ImageServer ImageServer            0 Aug 27 10:32 Folder B
> drw-------   1 ImageServer ImageServer            0 Aug 27 10:32 Workspace
> 226 Closing data connection.
> 
> Note; Uploading a file through the Mac OS-X console using "put 
> filename.ext" works fine in Workspace.
> It is uploading through the native Finder ftp-support that fails.
> 
> Again, any advice (from anyone) would be appreciated, but I'm not 
> expecting anyone to do my legwork :)
> 
> Best regards,
> 
> Joakim Back
> 
> Niklas Gustavsson skrev:
>> I know nothing about this specific client. However, one thing that 
>> might give a clue is what a LIST would return showing those 
>> directories. The LIST result contains the access for the user, based 
>> on hasReadPermission() and  hasWritePermission() on FileObject.
>>
>> /niklas
>>
>> Joakim Back wrote:
>>> Hello!
>>>
>>> I've been working with a virtual filesystem for a while, and so far 
>>> it's been working great. Now the issue is to support the most common 
>>> ftp-clients as to move away from the status as a novelty-feature.
>>>
>>> The one client I'm having issues with currently is the native 
>>> ftp-support in MacOSX (Finder?). The server transmits a user with 
>>> write permissions, and while most folders are not write-permissible, 
>>> there is an equivalent of an upload directory, the user Workspace 
>>> folder at root.
>>>
>>> The MacOSX native client disregards the unique folder permission and 
>>> decides that all directories at the server is read only. Has anyone 
>>> else had any experience with this? If I connect with the Transmit 
>>> program, everything works as expected, and also under Windows native 
>>> (Explorer?) and various clients.
>>>
>>> Using MacOSX 10.3.9, Finder 10.3.2.
>>>
>>> (To support MacOSX native client is important, as to be able to 
>>> connect the FTP-server as a remote-drive for seamless integration.)
>>>
>>
>>
> 
> 


Re: Write-permissions under MacOSX

Posted by Joakim Back <jo...@notitium.se>.
I'm not sure how to further debug this issue, which is why I'm posting 
already with little new information to provide.

Here's the list result (fixed-width formatting);

Windows cmd:

ftp> ls
200 Command PORT okay.
150 File status okay; about to open data connection.
dr--------   1 ImageServer ImageServer            0 Aug 27 08:57 Folder A
dr--------   1 ImageServer ImageServer            0 Aug 27 08:57 Folder B
drw-------   1 ImageServer ImageServer            0 Aug 27 08:57 Workspace
226 Closing data connection.

Mac OS-X shell:

ftp> ls
229 Entering Passive Mode (|||3450|)
150 File status okay; about to open data connection.
dr--------   1 ImageServer ImageServer            0 Aug 27 10:32 Folder A
dr--------   1 ImageServer ImageServer            0 Aug 27 10:32 Folder B
drw-------   1 ImageServer ImageServer            0 Aug 27 10:32 Workspace
226 Closing data connection.

Note; Uploading a file through the Mac OS-X console using "put 
filename.ext" works fine in Workspace.
It is uploading through the native Finder ftp-support that fails.

Again, any advice (from anyone) would be appreciated, but I'm not 
expecting anyone to do my legwork :)

Best regards,

Joakim Back

Niklas Gustavsson skrev:
> I know nothing about this specific client. However, one thing that 
> might give a clue is what a LIST would return showing those 
> directories. The LIST result contains the access for the user, based 
> on hasReadPermission() and  hasWritePermission() on FileObject.
>
> /niklas
>
> Joakim Back wrote:
>> Hello!
>>
>> I've been working with a virtual filesystem for a while, and so far 
>> it's been working great. Now the issue is to support the most common 
>> ftp-clients as to move away from the status as a novelty-feature.
>>
>> The one client I'm having issues with currently is the native 
>> ftp-support in MacOSX (Finder?). The server transmits a user with 
>> write permissions, and while most folders are not write-permissible, 
>> there is an equivalent of an upload directory, the user Workspace 
>> folder at root.
>>
>> The MacOSX native client disregards the unique folder permission and 
>> decides that all directories at the server is read only. Has anyone 
>> else had any experience with this? If I connect with the Transmit 
>> program, everything works as expected, and also under Windows native 
>> (Explorer?) and various clients.
>>
>> Using MacOSX 10.3.9, Finder 10.3.2.
>>
>> (To support MacOSX native client is important, as to be able to 
>> connect the FTP-server as a remote-drive for seamless integration.)
>>
>
>


-- 
Best regards,

Joakim Back



Re: Write-permissions under MacOSX

Posted by Niklas Gustavsson <ni...@protocol7.com>.
I know nothing about this specific client. However, one thing that might 
give a clue is what a LIST would return showing those directories. The 
LIST result contains the access for the user, based on 
hasReadPermission() and  hasWritePermission() on FileObject.

/niklas

Joakim Back wrote:
> Hello!
> 
> I've been working with a virtual filesystem for a while, and so far it's 
> been working great. Now the issue is to support the most common 
> ftp-clients as to move away from the status as a novelty-feature.
> 
> The one client I'm having issues with currently is the native 
> ftp-support in MacOSX (Finder?). The server transmits a user with write 
> permissions, and while most folders are not write-permissible, there is 
> an equivalent of an upload directory, the user Workspace folder at root.
> 
> The MacOSX native client disregards the unique folder permission and 
> decides that all directories at the server is read only. Has anyone else 
> had any experience with this? If I connect with the Transmit program, 
> everything works as expected, and also under Windows native (Explorer?) 
> and various clients.
> 
> Using MacOSX 10.3.9, Finder 10.3.2.
> 
> (To support MacOSX native client is important, as to be able to connect 
> the FTP-server as a remote-drive for seamless integration.)
>