[Dave N]

I regularly need to transfer files from a Red Hat server to my Mac, but lately the server has been very Mac unfriendly using the Finder's "Connect To Server" GUI.

I can log into the server with the terminal via ssh, but I don't know the command to transfer my files over to my Mac. I would like the files to remain on the server after transfer.

Can anyone tell me the command, paths, etc.?

[Earth Mk. II]

well.. there's sftp - basically an ftp client tunneled over ssh.

and there's scp - secure copy. Syntax is similar to the normal cp command, except with user and host declared. For example:

To pull files off a server: scp user@host:/path/to/files /path/to/local/dir

To put files onto a server: scp /path/to/files user@host:/path/to/remote/dir

To transfer files between 2 remote hosts: scp user@host1:/path/to/files user@host2:/path/to/host2/dir

scp has the advantage of being only one command, and accepting wildcards, transferring whole directories (-r switch), and basically anything else normal cp can do. It even uses most of the same switches as cp.

hope that helps.

[Dave N]

Thanks a lot -- that worked fine!

Edit: Oops, except that the file associations were not preserved, and I cannot open it...

[schwa]

cp (and, I assume scp by extension) is a poor tool for copying any files you want to use through the GUI, since it doesn't preserve resource forks.

sftp is a good option (Transmit supports it, and I think Fugu does as well, if you want to avoid the command line), but your best bet may be a combination of tar + scp.

[Moonray]

Linux does not know about resource forks at all, so scp and ftp will copy all of the files completely (where ftp has the advantage that you are able to resume transfers).
What file associations do you mean?

-

[Dave N]

Originally posted by Moonray:
Linux does not know about resource forks at all, so scp and ftp will copy all of the files completely (where ftp has the advantage that you are able to resume transfers).
What file associations do you mean?

-

I'm not sure if "file associations" is exactly the proper term here, but the file came over as a white "unknown" file. I went to the "get info" panel and told it which application to open with. All the apps were grayed out under the "recommended" option, so I chose the "all applications" and selected the app that this file should open with (an OS 9 app, in this case). The file was still an unknown white type, and I still could not open it.

Is there any other way to get my files from this server thru OS X without using appletalk? (I'm assuming here that when I "connect to server" from the finder it is using appletalk.) I think the server is running netatalk -- they just switched it over from Debian to RedHat and they're having some problems.

[Detrius]

Originally posted by Dave N:
I'm not sure if "file associations" is exactly the proper term here, but the file came over as a white "unknown" file. I went to the "get info" panel and told it which application to open with. All the apps were grayed out under the "recommended" option, so I chose the "all applications" and selected the app that this file should open with (an OS 9 app, in this case). The file was still an unknown white type, and I still could not open it.

Is there any other way to get my files from this server thru OS X without using appletalk? (I'm assuming here that when I "connect to server" from the finder it is using appletalk.) I think the server is running netatalk -- they just switched it over from Debian to RedHat and they're having some problems.

If the file has the filename extension at the end, you shouldn't have this problem. I have seen similar issues in copying Mac files to PCs and back again. Without the filename extension, the OS has no clue what kind of file it is.

[Earth Mk. II]

What's probably happening is the server (netatalk) is somehow specially handling the mac's resource fork so that it's compatible with the linux server's filesystem. This would happen transparently to any AFP clients on the network.

So, when you copied the file to the linux server through AppleTalk, it's metadata (resource fork) was preserved in the server's own format. But, when you pulled it off using scp or sftp, the resource fork had been stripped from the file and only the data fork was left because the server didn't have a chance to recombine the two forks.

Unfortunately, I've never had any experience using AFP on a *nix server... so I can only guess.

[Earth Mk. II]

doing a little more research, look for a hidden directory where your files are (ls -a).. It could be named something like .resource.

Copy those files to your mac, and copy them into the resource fork using cp, by appending '/rsrc' onto the end of the filename of the data fork.

e.g.: cp /path/to/fileRsrcFrk /path/to/file/rsrc

[Moonray]

The other possibility is that the resource fork is stored in a file with an underscore plus the same filename on the same level as the data file is. If you are really talking about resource-fork files and that server is running netatalk there might be a netatalk option to switch between the old and new resouce-fork format, maybe it's set the wrong way.

-

[[APi]TheMan]

Originally posted by Earth Mk. II:
doing a little more research, look for a hidden directory where your files are (ls -a).. It could be named something like .resource.

Copy those files to your mac, and copy them into the resource fork using cp, by appending '/rsrc' onto the end of the filename of the data fork.

e.g.: cp /path/to/fileRsrcFrk /path/to/file/rsrc

Interesting. That's good to know, but man, I haven't needed to deal with resource forks in forever... though I imagine the need to deal with resources in an environment continually moving away from Mac OS 9 is becoming less and less common, I'll keep that tip in mind, cuz it's still pretty sweet.

[utidjian]

Originally posted by Earth Mk. II:
What's probably happening is the server (netatalk) is somehow specially handling the mac's resource fork so that it's compatible with the linux server's filesystem. This would happen transparently to any AFP clients on the network.

So, when you copied the file to the linux server through AppleTalk, it's metadata (resource fork) was preserved in the server's own format. But, when you pulled it off using scp or sftp, the resource fork had been stripped from the file and only the data fork was left because the server didn't have a chance to recombine the two forks.

That is exactly what happens. Netatalk, when set up correctly, on a Red Hat Linux file server will act as an AFP server (also as a print server). The default configuration is quite simple... no editing of config files is required on the server.

When the Linux file server share is mounted on the Mac OS box via netatalk it will automatically create a .AppleDouble folder in each folder visited by the Mac. The .AppleDouble folder will have files in it named exactly the same as the parent folder. The files within the .AppleDouble folder are quite small, on my systems they are 589Bytes each. These files contain the resource fork metadata. All of this is handled transparently as far as the user is concerned. There is no visible difference between a genuine Apple file server and a Linux server using netatalk.

However... when one uses ftp/sftp/scp to move files to/from the Linux server the process is not carried out via the netatalk service. The ftp/sftp/scp services on the Linux server know nothing about the resource forks which are stored in the .AppleDouble folder(s).

Apple file servers that use HFS+ natively do essentially the same thing. However the resource fork metadata is stored within the filesystem itself.

There will be a disconnect between files and their resource forks between a Mac OS client and a Linux server if one mix and matches the way files are moved between them. For my systems... the Mac OS 9.x and older clients always interact with the Linux server as an AFP server via appletalk/netatalk. This has worked well for us for about 4 years. I can even copy the entire Macintosh HD from a Mac OS9 client to the server as a backup or clone image. Then I can boot a Mac from the install CD, mount the share from the server via the chooser, and copy the entire disk over. Reboot and I have an exact clone of the original machine. This has worked very well for us. We originally used an Apple G3 server with an early copy of Mac OS X server. But we found the Linux server to be MUCH faster and more reliable (this was 4 years ago) I am sure (at least I hope) that Mac OS X server has improved since then for sharing files to Mac OS 9.x clients. We have found netatalk to be so reliable and relatively secure that we allow users to mount the server shares offsite. The users really like this because they can use the server from home as if it were a local disk.

Regardless of how the file sharing is setup between a Unix server (in this I mean Linux, Mac OS X, Solaris, *BSD) the clients shuold stick to one scheme or another. Either AFP/appletalk/netatalk or NFS. If you mix both on the client side you will have problems with the resource forks. The server can do netatalk/NFS/Samba all simultaneously without any problems.

To Dave N: If your server admins are having a hard time with netatalk on Red Hat Linux you can give them my email address dutidjia_at_ramapo.edu if they need some help straightening it out. I am currently running netatalk on Red Hat Linux and it works fine with very few problems.

[bradoesch]

Originally posted by Earth Mk. II:


:snip lotsa good stuff:

hope that helps.

I've been wanting to know that for a long time. I was always logging in with ssh and trying to go from there.

[Earth Mk. II]

Originally posted by bradoesch:
I've been wanting to know that for a long time. I was always logging in with ssh and trying to go from there.

Awww.. well.. shucks!

glad I could help

[Gavin]

An other option is rsync

it's designed to syncronize files from one machine to another.

The cool thing is that it only gets the part of the files that have changed so the transfer is very fast for tons of files.


I'm guessing that it has the same problems with the resource forks as the other tools.


Home Page

A Tutorial