Mac OS 9 Lives
Mac OS 9 Discussion => Hardware => Storage => Topic started by: Syntho on March 08, 2017, 06:25:00 PM
-
I'm going to get a Synology NAS soon and use SHR2 on it. I believe it runs some type of Linux distro. I learned my lesson long ago when storing Mac files on a Windows FTP that I set up. The resource forks wee destroyed and the files were damaged and unusable.
When I get this new NAS running, considering it's running on Linux, would it be ok to store Mac files on it 'raw' without bin'ing it up? i'm still not certain exactly how all of that works.
-
I wouldnt trust it to far. Novell is a better solution or if it can run a very old afp server there was a option in the config file for the forks. Dont know about newer versions. Moving from another system could destroy the file.
-
Synology does support AFP so the connection side should be fine.
I have never had ftp maintain the resource fork. AFP is aware of that so even if it stores the data and resource fork in two seperate files on the actual NAS, your mac would only see the one file. Just like how files are stored on a FAT partition as two files and the OS only shows it as one.
I have some friends who use them and we work with them at work as well. I can check and see how well it works with OS 9.
-
Worst comes to worst I'll just store backups as bin files.
-
like nano says, there can situations appear where the filesystem is not the problem but the combination with a certain transfer protocol will break stuff.
why dont you take the chance and sort your stuff. then you could create collections of bigger toast files or similar and use this to store the files in a linux nas.
-
As has been covered, storing a file on an ftp server can render the file useless due to it losing its resource fork. I noticed though that sit, hqx and sea files still work in Stuffit Deluxe regardless if that has happened. I also noticed it with audio files. I guess some software was programmed to ignore the resource forks and have it still work no matter what? I wish all software from that time did that.
PS: I thought that we were all supposed to create .bin files for uploading everything. I see a lot of file attachments on the forum without the .bin extension. It's mostly sit and hqx files, but as mentioned Stuffit is good about that. I guess if people were uploading other file types it would be a problem.
-
Synology does support AFP so the connection side should be fine.
I have never had ftp maintain the resource fork. AFP is aware of that so even if it stores the data and resource fork in two seperate files on the actual NAS, your mac would only see the one file. Just like how files are stored on a FAT partition as two files and the OS only shows it as one.
I have some friends who use them and we work with them at work as well. I can check and see how well it works with OS 9.
Did you ever try this on OS9?
-
many files simply do not have a resource fork, or at least no important data in it.
in the case of PCM audio, disc images or compressed archives all you loose is the custom icon, the type and creator info and the "get info" comment.
the same is true for most picture, video and text files.
-
in reply to your other thread (local NAS solutions):
the basic rules are:
1. you have to compress or container all applications. almost all executables use some resource fork data, such as the ones for windows.
2. you normally do not need to compress or container documents.
3. if you are unsure about a document type, just check its resource fork with resedit.
4.
.sit indicates OS9 files best.
.bin can be misleading when you browse it, but works as well and would be faster to create.
.zip is fast AND compresses but you should create them exclusively in OS9 (i.e. not in OSX) - and make sure that the filenames (or the folder it is in) are indicating that it is one OS9 and/or carbon application. (because otherwise someone might try to unzip them under windows, which brakes the file.)
5. because you never know what filesystems or protocols your file will see in the future, it´s best to leave the extensions as is. OS9 doesnt require them but they are an important part of the filename for yourself or others.
-
As has been covered, storing a file on an ftp server can render the file useless due to it losing its resource fork. I noticed though that sit, hqx and sea files still work in Stuffit Deluxe regardless if that has happened. I also noticed it with audio files. I guess some software was programmed to ignore the resource forks and have it still work no matter what? I wish all software from that time did that.
PS: I thought that we were all supposed to create .bin files for uploading everything. I see a lot of file attachments on the forum without the .bin extension. It's mostly sit and hqx files, but as mentioned Stuffit is good about that. I guess if people were uploading other file types it would be a problem.
Ok, to clarify... The loss of the "creator" will break the file's association, Not render it useless.
So, newbies will still have trouble with archives if they do not drag the file manually onto the unstuffit app or simply open StuffIt first and select the file. Either way the file will lose it's icon.
the reason we encode the file (make it a .bin), is to wrap it up in a neat little data bundle that preserves all file info from both forks and When it is unencoded, all is as it was including the "creator" or associated application.
The .bin process of encoding with mac binary does not compress or pack the contents like a StuffIt it archive, again, it simply puts the file contents and resource fork into a neat package with no compression added.
Hqx is a different story, it was made to be stored on non-Mac file systems and self extracts, but is better than a .sea since it cannot get compromised from loosing the resource fork.
lastly, files will all "still work" after being stored on non-Mac systems, but applications may crash and manual file fixing via "file type" of other utilities may be needed if the application does not "look" at the data file's contents and simply expects it to have been created by another app, and now that info is missing from a stripped resource fork.
Wav files will still have digital audio, text files will still contain text, but trust me, this encoding thing is absolutely critical if you plan to use your files without dedicating a lot of time fixing them
-
Ok, to clarify... The loss of the "creator" will break the file's association, Not render it useless.
So, newbies will still have trouble with archives if they do not drag the file manually onto the unstuffit app or simply open StuffIt first and select the file. Either way the file will lose it's icon.
the reason we encode the file (make it a .bin), is to wrap it up in a neat little data bundle that preserves all file info from both forks and When it is unencoded, all is as it was including the "creator" or associated application.
The .bin process of encoding with mac binary does not compress or pack the contents like a StuffIt it archive, again, it simply puts the file contents and resource fork into a neat package with no compression added.
Hqx is a different story, it was made to be stored on non-Mac file systems and self extracts, but is better than a .sea since it cannot get compromised from loosing the resource fork.
lastly, files will all "still work" after being stored on non-Mac systems, but applications may crash and manual file fixing via "file type" of other utilities may be needed if the application does not "look" at the data file's contents and simply expects it to have been created by another app, and now that info is missing from a stripped resource fork.
Wav files will still have digital audio, text files will still contain text, but trust me, this encoding thing is absolutely critical if you plan to use your files without dedicating a lot of time fixing them
Yeah…What HE said…
-
There are multiple ways to go about it then. An sit, sea, hqx OR bin seem to all salvage everything just fine from what you guys are saying. I don't know which one to go with for personal use, but the bin extension seems to be the one that DH wants for the community.
PS: the NAS thread still has a lingering question: if using AFP/Appletalk will preserve everything without having to bin everything up. But that's for that thread -afro-
-
From Gary...
Yeah…What HE said…
LMAO cause that's what I wanted to add after many Gary posts
-
PS: the NAS thread still has a lingering question: if using AFP/Appletalk will preserve everything without having to bin everything up. But that's for that thread
Ok, let's try this on the NAS side. I fear we are going to jumble a bunch of networking protocols together and also mix in some file storage systems and get the important stuff lost in the mix, but here we go...
Background:
AppleShare was a product from Apple Computer which implemented various network services. Its main purpose was acting as a file server, using the AFP protocol (Apple Filing Protocol, formerly AppleTalk Filing Protocol).
.
So, to break this down, the Server could be a Mac box or Novell PC Server (running Mac modules and Name space) or a Windows NT/2000 Box running Services for Macintosh... or as you mentioned a NAS Box... but the NAS box scenario, the NAS must first have the ability to store files with HFS support if you are going to want to preserve file resource forks from the classic mac OS (Mac OS 8 & 9). Or a means to emulate this, by storing the data and resource fork as two separate and a way to make this transparent to the client (workstation). Usually, NAS Boxes support Mac OS X (with no resource forks), but omit OS 9 support... so maybe a cheap NT box with RAID support may be a better route ? The Appleshare Server basically broadcasts that it is a classic mac file repository and the "network protocols" take over to transmit the data over a wire for the client...
Earlier versions of AppleShare supported only the AppleTalk network transport protocol but later versions, sold under the name AppleShare IP, allowed use of the TCP/IP protocol stack, as used on most modern networks. AppleShare provided three different protocols for application-layer services: AppleShare File Server, AppleShare Print Server and AppleShare PC.
Also to note: AppleShare can operate with any physical network medium. Early installations used mainly LocalTalk and more recently Ethernet but any physical medium could be used which could be directly or indirectly connected to an AppleShare server system.
More Background:
Equivalent third party server products include the open-source Netatalk suite on Unix-like systems, and Services for Macintosh on Microsoft Windows NT and 2000. Versions of Mac OS from System 7 onwards included Personal File Sharing, which is a more limited AFP implementation. The most obvious difference between Personal File Sharing and AppleShare is that the former supports only a small number of concurrent remote users.
All versions of Mac OS were capable of acting as a client to an AppleShare server (via AFP and later SMB) over AppleTalk and TCP/IP protocols, although more recent versions of macOS have gradually removed support for AppleTalk in favor of the standard TCP/IP. Third-party vendors created client software such as PC MACLAN (discontinued) and DAVE to implement client functionality on Windows systems. Other developers offered server software that provided similar functionality on Windows Servers such as GroupLogic ExtremeZ-IP and Cyan Software MacServerIP and NetATalk on Linux. Later versions of AppleShare also implemented the SMB and CIFS protocols which are the native file sharing protocols on Windows machines.
So again, in our world... we would use Ethernet wiring and cards, a switch/hub... and a Modern NAS, simple, right ? WRONG, the modern evolution of AFP is NOT the same thing as older literature that refers to AFP as "AppleShare", the name of the Mac OS 9 (and earlier) AFP client. So the problem, connectivity to both Mac OS 9 and Mac OS X clients is fine, but NO support for the Classic Mac OS resource fork when storing files on the NAS...
Questions ?
Answers ?
-
Related Info:
In 1998, Apple introduced HFS Plus to address inefficient allocation of disk space in HFS and to add other improvements. HFS is still supported by current versions of Mac OS, but starting with Mac OS X, an HFS volume cannot be used for booting, and beginning with Mac OS X 10.6 (Snow Leopard), HFS volumes are read-only and cannot be created or updated. In macOS Sierra, Apple's release notes state that "The HFS Standard filesystem is no longer supported." However, read-only HFS Standard support is still present in Sierra and works as it did in previous versions.
As a last point... we have proven and showed that even mounting OS 9 volumes (and having spotlight searching) in early versions of OS X (10.4 and 10.5) will eventually write info the the file catalog that OS 9 will not understand and create betree errors when testing those volumes in Mac OS 9. So, I personally recommend keeping OS X and 9 on separate PPC computers
-
wtf appletalk. and i thought i am oldschool. i already think that 100mbit network connections are too slow for filetransfers. but appletalk?
firewire is a mean bottlenack already if you deal with bigger files, leave alone networking.
-
So basically, DH, I can forget using my Synology NAS if I expect it to not screw with any of my files at all, and Nanopico is wrong since even though my NAS supports AFP, it's the nu-school AFP and not the old one?
It would be really nice to have a simple backup server for my important Mac files, so I guess I'll look into something else instead of using my main NAS. I could just bin everything up I guess, but I'm lazy...
-
I really didn't want to confuse everyone with this NAS thread. Many NAS boxes are Mac OS compatible as far as OS X, and OS X (pre-snow leopard) fully supports the Mac OS 9 file structures... however, there are still many variables of which client is used on the computer which is transferring/writing and reading the files. This is NOT a discussion for all, so don't feel left out if you are a little confused.
More Useful (or useless) info:
Many NAS Boxes claim "Mac Support" via SMB
Using the Mac OS X File System Client
This option is based on Microsoft’s SMB/CIFS protocol and is built into Mac OS X. Microsoft designed SMB as a proprietary
protocol to support Windows file sharing. In other words, SMB was not designed for the Mac.
The SMB client makes the Mac look like a Windows client, but the Mac has to make compromises because it is acting like
Windows and some of the core features of Mac OS X don’t map well to this protocol. For example, recent innovations in Mac OS X, including Time Machine backups and Network Spotlight, are only available over the AFP protocol.
The SMB client’s approach to supporting the unique Mac file structure presents challenges. When the SMB client transfers Mac files to the Windows environment, it can separate the data file from its metadata and creates hidden “._” files that hold the Mac resource fork and Finder information in a format known as AppleDouble. This transfer method is one of the central difficulties for Mac and PC users.
Mac OS X or Mac OS 9 clients previously connecting to SFM used AFP, not the SMB client, and files transferred with AFP are stored differently. AFP servers use NTFS alternative data streams and do not create “._” files during a transfer, which means all of the legacy data on a Windows file server is in this format. The Mac OS X SMB client does not recognise this format. When the Mac OS X SMB client goes to the server to look for data, it looks for the “._” files and, when it doesn’t find them, assumes they do not exist. Valuable metadata is lost. Files lose their association with applications. This is a major issue for companies with legacy data and for mixed Mac OS 9 and Mac OS X environments.
These hidden “._” files confuse Windows users and result in deleted and moved data files and the loss of critical data. Because these files are hidden, they are easily disconnected and lost from the main data file by accident when files are moved, renamed, or archived. The result is data loss for the Mac client, including the loss of association of a file to the application that created it. In addition in situations where when a user may lock a “._” file or change permissions the data file may not open.
I only bring this up because things get really crazy when we introduce OS X units and really out of control when we add Windows clients. The take away from this is that there are many scenarios that can fuck the resource fork out of existence even on a system that stores it by another method like "._" hidden files. Remember, it may not be obvious to those who administer and backup the NAS and they may "accidentally" nuke the saved forks (since they are actually saved as different files).
So, back to reality... I was only anti-NAS because there are much easier ways to setup an OS 9 archive, these are the order of my favorites:
1) A RAIDED OWC Dual Mini FW400/800 (fully explained in other posts) - Has Hardware RAID with 2 Laptop HDs or SSDs
http://www.thessdreview.com/featured/owc-mercury-elite-al-pro-dual-mini-raid-data-storagebackup-review/2/
Has FW400, FW800, and USB (the new Model is USB 3 with no FW, so get the older Model). Move to other OS 9 units with ease and data integrity.
2) A Novell Server 3.11 with RAID on an Ancient PC with Mac Services loaded and Mac Name space; stores Mac OS 8 & 9 files flawlessly. But if you never did Novell, may be hard, much faster than MS NT
3) NT/2000 Pro Server with Services for Mac (2 GB File size limit)
-
take this only as an opinion expressed (i.e. i could be wrong or not seeing your situation) but the only scenario where a network attached disk makes sense are those where you have the need to connect differeent computers - especially with with different OSes - to the database.
with an NAS you can access the files with different protocols and set up different users and groups. as an additional bonus you can attach it to more than a local network as well, you can make it a public ftp server in the internet when required.
they key feature - and the only thing what makes it superior to usb, firewire or esata is that you can easily put it at a 24 port ethernet switch and share the same data among 24 clients. or you use a full featured router and connect with 8 clienst at the same time but with 8 different protocols.
if you would try the same with firewire disks and a firewire hub that will cost you a few hundred bucks and one wrong connection can destroy your data.
for storing mac os 9 apps, your stock audio library or your rendered video output an NAS could work - but personally i would never (again) try to use such a NAS enclosure, rather i use a "normal" computer for that purpose.
say like a macmini with linux or osx. it will consume 25 watts where the enclosure will need 10, but it allows you configure any service protocol you want and that all with a neat graphical interface (via vnc or by connecting a small monitor)
-
Yes... good Point IIO, the non-NAS solution was for users with a few (1 to 3) PPC Classic Mac OS Systems.
I setup a Novell server with about 10 mac clients that ran in the basement of a studio in NY, they had 5 project rooms and 3 live rooms for rehearsal and they also recorded the rehearsal rooms at 5 to 8 tracks each to the local hard drives, they then copied tracks to and from the server with no issues to different rooms.
They were even able to play 8 tracks over the wire in CuBase with the tracks being streamed of the server with no issues.
-
I'm thinking the best option for me is to just bin or sit everything up and put it on a my NAS. It's great to have a central location where literally my entire house/studio has backup support. I'll just have to remember to bin or sit everything before putting it on there, except for files that won't matter like audio files. They immediately get the Quicktime creator type when I download them via FTP. I wonder how that is though. Hmm..
But this leaves me with two questions:
1) I like the simplicity of Drop Stuff for stuffing files, usually the one built into the OS. But if I want to bin something up, which versions of Stuffit do that? I think I'm using 7 Deluxe. Is there something less cumbersome than that?
2) Instead of using Fetch or FTP at all, should I turn on the file sharing stuff to make all of this more efficient? Uploading and downloading files via FTP was pretty buggy at times anyway.
-
They immediately get the Quicktime creator type when I download them via FTP.
quicktime often grabs files with no creator. you can uncheck most of that in its prefs.
1) I like the simplicity of Drop Stuff for stuffing files, usually the one built into the OS. But if I want to bin something up, which versions of Stuffit do that? I think I'm using 7 Deluxe. Is there something less cumbersome than that?
cant remember where, but there was something like a dropbox like service for OS9 where you drag files onto the app and it stuffs and ftp-sends them. couldnt you use the official dropbox client locally?
-
greetings fellow mac enthusiasts!
for a fileserver serving up files to multiple Macs running os7/8/9; i think there is a very simple solution for the technically uninclined who dont want a big headache to accomplish the task:
i know that if you have an intel OR ppc mac running Mac OSX Leopard (10.5.x)
it is unique in comparison to more recent Mac OSX machines, in that it can connect to/from older pre-osx macintosh machines using AFP filesharing!
(just do cmd-k, go, afp://192.168.x.x, boom! it works!)
as far as i recall, it even works both ways! allowing osx to connect to os9 as a client, and allowing os9 to connect to osx as a client (can anyone else confirm this?)
might work in snow leopard aswell, but as we all know, this obviously does not work with 10.10 Lion and above! as the story goes, AFP compatibility was originally broken with the tiger 10.4.3 update but i think they did an about-face and reversed the change that caused the incompatibility either in 10.4.11 or 10.5 or an update to 10.5 (not sure, would have to fact check!)
hope this helps!
perhaps its not as helpful as i thought in this day + age as many people , having to choose, would probably select a different version of OSX to run on their hardware! ie: g4 users would choose to run Tiger as its a bit lighter on the ppc hardware, and intel mac users would choose to run snow leopard! Leopard is left in the lurch...
-
using a PC as fileserver will eat up a lot of household electricity ;)
-
using a PC as fileserver?
"MacServerIP 9.0 Long file name & AFP 3.1 & Tiger MacOSX support; extremely fast file server for Mac clients; speed up file transfer between Macs and Win 2003/XP/2000/NT/Win 2008/Windows 7/Vista x32/x64 by up to 5 times."
http://www.cyansoftware.com/download.htm
http://www.cyansoft.info/macsrvip9.zip
the testimonials seem very positive!
cheers!
-
for any MacOS9 client your speed will be limited by the 100mbit ethernet connection. the only how to make it faster would be to use firewire. but then the cost for a bigger switch would be higher than for ethernet.
even if you were right and a computer would be 5 times faster than a NAS it will probably not be worth the energy it uses up.
-
greetings!
last night i was able to test the file server software i posted above
i did have to right click + "run as administrator" otherwise it would not install properly.
i was then able to mount the shared folder/volume on system 7 on my macintosh SE machine by entering the
PCs IP address in the chooser! it also works to mount the shared folder/volume on modern intel mac!
ta da! it works!
-
[youtube]GgdwneSi5Qg
Made a short video, i dont like the struggling part and the worrys.
Just go with what works and forget the rest.[/youtube]
-
So maybe I should just try Thursby software on a Mac. Hmm. The page says it's compatible with a NAS running Linux though, and a Synology NAS does just that I think.
-
Yes, what i said was dont move your files around in other operating systems. If you read how dave stores the fork you may not like it. At first i wasn't really happy about it but i had to use it with avid software for a while. Technically you can connect to pretty much anything but from vista ongoing you have to drop the 128bit encryption. And one more thing i use the usb plug on a airport extreme to share drives. Can't get more compatibility than that :D
-
Yes, what i said was dont move your files around in other operating systems. If you read how dave stores the fork you may not like it. At first i wasn't really happy about it but i had to use it with avid software for a while. Technically you can connect to pretty much anything but from vista ongoing you have to drop the 128bit encryption. And one more thing i use the usb plug on a airport extreme to share drives. Can't get more compatibility than that :D
using AFP as the connection for file services protects the resource fork + metadata (even when its going to an alien OS!) .. that is why its called Apple Filing Protocol
https://en.wikipedia.org/wiki/Apple_Filing_Protocol
The Apple Filing Protocol (AFP), formerly AppleTalk Filing Protocol, is a proprietary network protocol, and part of the Apple File Service (AFS), that offers file services for macOS and the classic Mac OS. In macOS, AFP is one of several file services supported, with others including Server Message Block (SMB), Network File System (NFS), File Transfer Protocol (FTP), and WebDAV. AFP currently supports Unicode file names, POSIX and access control list permissions, resource forks, named extended attributes, and advanced file locking. In Mac OS 9 and earlier, AFP was the primary protocol for file services[/b]
the Dave app gets its name from WebDAV i think..
but yes PRIMARY PROTOCOL for FILE SERVICES..
i dare you to compare transfer speed AFP vs SMB vs NFS vs FTP vs WEBDAV
i already did my own tests so i know which one will win!
AFP gives the fastest throughput.. hands down.
as long as both source location + destination support AFP..
using a server with modern PC hardware that ssupports AFP will
give you mindblowingly fast speed so fast that you will forget its
a network drive.. because it mounts to your desktop, gets accessed
via native os9 finder, you will forget its network drive!
with gigabit ethernet interfaces on both machines + proper CAT5e cabling, its faster than firewire.
yes faster than firewire. i use a RAID setup on my fileserver and its consistantly 80MB/s+
-
I'm going to get a Synology NAS soon and use SHR2 on it. I believe it runs some type of Linux distro. I learned my lesson long ago when storing Mac files on a Windows FTP that I set up. The resource forks wee destroyed and the files were damaged and unusable.
When I get this new NAS running, considering it's running on Linux, would it be ok to store Mac files on it 'raw' without bin'ing it up? i'm still not certain exactly how all of that works.
https://www.synology.com/en-global/knowledgebase/DSM/help/DSM/AdminCenter/file_winmacnfs_mac
enable AFP and disable the other protocols and you should be rock n roll'in with fast AFP transfers
have u tried this yet? if not you dont know what your missing..
simply enable AFP on the NAS..
and then mount the network drive on mac os 9 natively
u dont need any program at all to access it .. support is built in to the mac os 9 os!
and AFP server shoudl automagically handle everything to the point that u can forget about it
and YES using this method u can drag the files without bin'ing them up.
drag n drop from macos9 machine #1 to NAS.. then drag n drop to macos9 machine #2 from the NAS and all icons + thumbnails + resource forks will be as they should be
if u dont have a nas, another good solution is to use an OSX Leopard server (10.5) enabling AFP and same method, simply mount on os9 desktop and works great!
what else would you expect from a protocol that was custom made for MACOS!
-
for any MacOS9 client your speed will be limited by the 100mbit ethernet connection.
?? not if you install a Gigabit Ethernet PCI Card..
ive used one from TrendNet on my sawtooth + yosemite b+W and it works fabulous.
-
Worst comes to worst I'll just store backups as bin files.
you would only need to encapsulate your files if you have a situation where you cannot use AFP
or one of the two (source vs destination) does not support AFP.
please read:
https://en.wikipedia.org/wiki/Resource_fork
Compatibility problems[edit]
The complexity of programming with resource forks has led to compatibility problems when accessing other file systems via file sharing protocols such as AFP, SMB, NFS and FTP, when storing to non-HFS volumes, or when transmitting files to other systems in other ways (such as via email). The AFP protocol natively supports Resource Forks, and so resource forks are typically transmitted to these volumes as-is, and stored by the server transparently to clients. The SMB protocol supports a file metadata system similar to Macintosh forks known as Alternate Data Streams (ADSes hereafter). macOS did not support storing resource forks in ADSes on SMB volumes by default until Mac OS X v10.6. In previous versions of the OS, including upgraded versions of 10.6, this feature can be enabled with a param change or by creating a special file.[3]
NATIVELY. built in support for resource forks + meta data
as-is meaning seamless integration u dont have to stuffit or zip or bin its just seamless integration
u can drag your whole drive if u want over AFP and it will be fine
-
So maybe I should just try Thursby software on a Mac. Hmm. The page says it's compatible with a NAS running Linux though, and a Synology NAS does just that I think.
it's running Linux, but a very special version (had a couple of them over several years in pro office use)
Very nice boxes and (tbh) the 'better' MacServer regarding simplicity of administration.
Synology is not just about storage but a lot of rather well considered network applications, too.
I still have one around and will check it with OS9 next time, but also with sharing audio files between Windoze, IOS and OS9.
-
I'm using OS8.6 on my 9600. I see an Adobe thing in the Chooser but not Appleshare. My OS9 laptop does show the Appleshare thing though. Is there some other way to mount the NAS s a network disk in OS8.6?
PS: I'm late to the party on knowing this, but I always wondered why DAWs won't work if you have Appletalk turned on. Why is that?
-
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=3714.0;attach=4703;image)
according to this book:
https://books.google.ca/books?id=r64VJt0a4WsC&pg=PA68&lpg=PA68&dq=mac+os+8.6+chooser+appleshare&source=bl&ots=tKmmZi-d4C&sig=UP-x2D2N_EmYwk4S7T5SF-lf0i8&hl=en&sa=X&ved=0ahUKEwjw_YSwiujXAhVs4YMKHc6bB8sQ6AEITzAG#v=onepage&q=mac%20os%208.6%20chooser%20appleshare&f=false (https://books.google.ca/books?id=r64VJt0a4WsC&pg=PA68&lpg=PA68&dq=mac+os+8.6+chooser+appleshare&source=bl&ots=tKmmZi-d4C&sig=UP-x2D2N_EmYwk4S7T5SF-lf0i8&hl=en&sa=X&ved=0ahUKEwjw_YSwiujXAhVs4YMKHc6bB8sQ6AEITzAG#v=onepage&q=mac%20os%208.6%20chooser%20appleshare&f=false)
according to this book it says that mac os 8.6 + earlier cannot use Appleshare over TCP
meanwhile i just logged in to my fileserver on my b+w g3 450mhz running 8.6 so that cant be true..
just another example of mis-information on the net.. obviously the author of the book above meant to report
the facts, and probably did so as he or she understood them to be true, but they are in fact wrong!!
because i just used both 7.5.5 + 8.6 to connect to my AFP Fileshare.. it works, and it works beautifully + FAST!
and natively mounted on the desktop and accessed via the finder as one accesses a local drive.
so if you click on appleshare, it doesnt show the "server ip address" button??
(http://kobiljak.msu.edu/training/Orientation/Graphics/mac_chooser.gif)
also i note that when i click appleshare on my 7.5.5 machine it says "7.5.5" in the bottom right hand corner of the chooser..
but on my 8.6 machine it says "7.6.2", im not sure what this number is referring to exactly.. maybe thats the "appletalk" version? either way this number has nothing to do with the appleshare client version apparently.
like i said its really confusing because the names of the technologies are so similar and not really defined or distinguished from one another...i just found this installer on my 8.6 mac b+w g3, i think maybe i installed it?
"appleshare_client_3.7.4.img.bin"
https://www.fenestrated.net/mirrors/Apple_Support_Area/Apple_Software_Updates/MultiCountry/Macintosh/Networking-Communications/AppleShare_Client/AppleShare_Client_3.7.4.img.bin
https://www.fenestrated.net/mirrors/Apple_Support_Area/Apple_Software_Updates/MultiCountry/Macintosh/Networking-Communications/AppleShare_Client/AppleShare_Client_3.7.4_Info.txt
i cant remember if i had to install something to get that server ip address thing to show up
i know i had to install that on my 7.5.5 system to get it to work..
i just found the following statement on google:
(AppleShare Client 3.7 or higher is required for AFP- over-IP access)
http://abekas.com/download/Legacy_Products/Accom_Legacy_Products/WSD/WSD-HD/interface_documents/wsd-hd_macserverip.pdf was in this document for macserverip software
heres a good quote from that pdf:
MacServerIP Product Information
MacServerIP is an AppleTalk File Protocol (AFP) server product that supports access using Internet
Protocol (IP), adhering to the specifications developed by Apple Computer for its AppleShare IP products.
MacServerIP allows Macintosh computers to access the WSD/HD and transfer files using IP instead of the
AppleTalk Datagram Delivery Protocol (DDP).
The IP method offers significantly better performance than DDP — making it possible for users to access the WSD/HD from anywhere in the world via the Internet, when using the standard AppleShare Client Software provided in MacOS 8.1 and higher or System 7.6 and higher with AppleShare Client Software installed (AppleShare Client 3.7 or higher is required for AFPover-IP access).
now that was in reference to the macServerIp software, but it does exactly the same thing as any other AFP fileserver... be it nas4free or a real mac os x install (10.5), the client is neccessary to access it, so you can only access it on 7.6 + higher (even tho i got it working on 7.5.5 after reading this page i think: https://www.fenestrated.net/mac/755/ )
-
https://en.wikipedia.org/wiki/Apple_Filing_Protocol
under compatibility
Compatibility[edit]
AFP versions 3.0 and greater rely exclusively on TCP/IP (port 548 or 427) for establishing communication,
supporting AppleTalk only as a service discovery protocol.
The AFP 2.x family supports *both* TCP/IP (using Data Stream Interface) *and*
AppleTalk for communication and service discovery.
Many third-party AFP implementations use AFP 2.x, thereby supporting AppleTalk as a connection method.
Earlier versions rely exclusively on AppleTalk.
For this reason, some older literature refers to AFP as "AppleTalk Filing Protocol".
Other literature may refer to AFP as "AppleShare", the name of the Mac OS 9 (and earlier) AFP client.
Notable current compatibility topics are:
-Mac OS X v10.4 and later eliminates support for AFP servers that rely solely on AppleTalk for communication.
-Computers using classic Mac OS can connect to AFP 3.x servers, with some limitations.
For example, the maximum file size in Mac OS 8 is 2 gigabytes.
-Typically, Mac OS 9.1 or later is recommended for connecting to AFP 3.x servers;
for versions of original Mac OS prior to 9.1,
installation of the AppleShare client 3.8.8 is required.
and within the .txt file i linked above:
AppleShare Client 3.7.4 is included with Mac OS 8.1. (Previous
versions of the AppleShare Client software were known as the
AppleShare Workstation Software.)
not really sure if this means that the software was packaged + included as an optional install alongside mac os 8.1, or if it means that any system with 8.6 installed (or upgraded to?) should already have the appleshare client installed....
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=3714.0;attach=4705;image)
this lists which os versions need what appleshare client version
(taken from: http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Technologies/Apple%20AppleShare%20Client/About%20AppleShare%20Client%203.8.8.pdf (http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Technologies/Apple%20AppleShare%20Client/About%20AppleShare%20Client%203.8.8.pdf)
all those old versions appear to be here for download:
http://www.applefool.com/se30/
heres a download for 3.8.8
http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Technologies/Apple%20AppleShare%20Client/ (http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Technologies/Apple%20AppleShare%20Client/)
http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Mac%20OS%208.6/ (http://lists.cipiyou.be/%20Archives/Mac%20OS%20Classic/Apple%20Mac%20OS%207.0%20-%209.2/Apple%20Mac%20OS%208.6/)
-
I always wondered why DAWs won't work if you have Appletalk turned on. Why is that?
its because appletalk was over the same serial connection as the midi connection
and used the same resources.. and having both on at the same time was a recipe for failure
-
I don't see the Appleshare icon at all. It has an Adobe icon there, but no Appleshare.
-
I don't see the Appleshare icon at all. It has an Adobe icon there, but no Appleshare.
ok so... install the appleshare client
i attached it to the above post..
not sure how you dont have it already, but according to the info above,
v3.8.8 is the one you want to install if you are running os 8.6.
give that a shot and lets hear some test results
-
one other possibility that noone said is that u could use a classic mac as a afp/appleshare server
im pretty sure its speed wont contest at all with that of a intel core duo machine or higher with many hard drives..
but they can act as appleshare servers aswel i think with the installation of appleshare ip server i think
http://archive.org/download/download.info.apple.com.2012.11/download.info.apple.com.2012.11.zip/download.info.apple.com%2FApple_Support_Area%2FApple_Software_Updates%2FEnglish-International%2FMacintosh%2FNetworking-Communications%2FAppleShare_Client%2FAppleShare_Client_3.8.8.smi.bin
heres another download for 3.8.8 appleshare client (for users of os 8.6)
-
Dude... this works BEAUTIFULLY!!!
I dragged some SoundDesigner II audio files and some Sibelius files over to the AFP server on the NAS, then I uploaded those same files with a different name over Fetch FTP. I checked on my Macbook Pro and the NAS server is showing blank icons for the FTP files, but retained creator types/icons for the AFP ones.
I logged back into the NAS by mounting it on my 9600 and what do you know, the files are perfect.
DieHard mentions that even some OSX versions screw with the bitree for OS9 files. I'm kind of worried by reading what he's saying but my Synology NAS with SHR2 RAID setup is handling it fine. I'm doing it the other way around than DH mentioned though: mounting the NAS drive from OS9.
-
Dude... this works BEAUTIFULLY!!!
8) it does indeed
its insanely fast if u have a gigabit ethernet adapter (PCI)
-
I turned off Appletalk and the Appleshare thing still works. I thought it needed to be on? Man, I still don't know classic Mac OS's very well ;D
-
no it doesnt need appletalk to be on... its descended from appletalk...
but its not appletalk.. lol
its confusing.
pretty sure *that* Appletalk that you want to leave turned off is related to the serial modem/printer ports (which are powered by the serial UART) using appletalk with a serial cable to link two macs for example both macs would need to have turned on appletalk so that you could access the other machines files.. using the serial ports like a direct modem connection between the two.. accessed via serial port
appleshare client = AFP over TCP/IP (ethernet port)
yea once u have a mounted AFP share on your desktop..
it will keep it there after reboots
similar to how on windows you can map a network drive
-
I turned off Appletalk and the Appleshare thing still works. I thought it needed to be on? Man, I still don't know classic Mac OS's very well ;D
the naming is confusing indeed - this is a great site with comprehensive descriptions of all networking stuff for classic systems starting at day one... but it's easy to navigate to your specific system. In case you want the details you never wanted to know about ;)
http://www.applefool.com/se30/index.html
Congrats for getting your NAS running, the Synology boxes are versatile and very easy to manage.
(I even ran a full business mailserver on such a thing for years - and THAT is something)
If your system is relatively new and a typical 'home setup' you may consider to ignore the Raid feature (unless you use it for speed) and format it as 'just a bunch of disks'.
The Raid (standard setup) is cool for heavy business traffic with a lot of modified data at the minute level, but a total overkill with more or less static data and archives.
The disks don't stop spinning and shifting data around like madness - and it wears out regular harddisks in a couple of days. Synolgy suggests high endurance disk for a reason.
You can backup to one of the other volumes or an external USB/eSata disk in regular intervals automatically, which is secure and keeps the system nicely quiet.
-
I don't think OS8.6 has very good Keychain implementation. It asks me to type in the password every single time I reboot. In fact, I can't even find the damn Keychain control panel in OS8.6!
-
Astro: I have my surveillance cameras running 24/7 on it and I use it for important data backup. It automatically updates any files that change in the directories on my Mac Pro. Need to have multiple copies across disks for precious data!
-
yes, it depends a lot on your specific requirements and the disk count in the NAS.
Physical disk failure is a minor concern (with quality drives) today and the lower Raid levels don't offer much advantage or rather the opposite by increased wear.
Also to consider is factory faults mostly show up in certain production charges and one usually buys from the same lot. Thinking of the 2 drive versions here.
With 4 or more drives and online swapping capability it's a different story.
I just wanted to mention it because the difference can be a big one.
But whatever strategy you choose, Synology has you covered. I was really sceptical for it's Linux heritage, but eventually had to admit they did their homework better than Apple.
At that time we also had 2 MacMini Servers as an 'option', but they never got engaged.
ps: after some trouble finding back the PSU in the attic my own DS214 is running again and serves the old Mac fellas well. 500MB in one minute is quite ok with me. :)
Now data may flow from OS-9 to IOS to OSX to WinXP to Win7.
-
Physical disk failure is a minor concern (with quality drives) today and the lower Raid levels don't offer much advantage or rather the opposite by increased wear.
Also to consider is factory faults mostly show up in certain production charges and one usually buys from the same lot. Thinking of the 2 drive versions here.
With 4 or more drives and online swapping capability it's a different story
Well, I kinda have to differ with this statement...
1- I see brand new "high Quality" drives die all the time... some fail right out of the wrapper... quality control sucks these days
2- If the RAID implementation has elevator seeking (this reduces back-and-forth movements of the disk head and minimizes head seek times) and other tricks the drive do NOT suffer "increased wear" at all in a Mirror or RAID 5 configuration, so unless your storing Hollywood movies or other useless garbage, then I strongly suggest you throw a little "fault tolerance" into the mix... but that is just MO :)
-
agreed to the general context.
I noticed the 'wear thing' when using one of these NAS for developing with static database archive content for testing. Almost nothing was changed, but the drive activity didn't stop and it was happily blinking the whole day through ;)
After a couple of days the drives failed and were replaced by the same type, but configured as JBOD and that setup lasted for years.
-
Ok, weird problem here. I've always had an issue with downloading stuff via FTP from my mp3 folder, since 1) there's a LOT inside of it, and 2) old Macs don't seem to like long folder names or weird characters in it.
I tried browsing into the mp3 folder via mounting the NAS drive but Appleshare said there was an error and quit. Ever since, as soon as I open the network drive it defaults to the mp3 folder, then crashes.
I've deleted the Appleshare preferences but it keeps defaulting to the mp3 folder. Or at least, it defaults to the root directory of the NAS but has the mp3 folder's arrow icon ticked so the contents are expanded in List view. I need to close it somehow.
How can I reset this?
-
hope you got it sorted... the obvious method would be to access the NAS from another OS and move stuff from the offending folder temporarily. Or rename the original folder.
Check names for special characters like directory separators.
I remember some trouble with this when moving (real) old picture files to 'modern' storage.
At some point it stopped with 'directory not found' or similiar messages.
While I had the OS-9 part up and running in ten minutes, the thing is bitchy with IOS.
There's a supporting app that makes the shared folders available in IOS and you can write to them, but import from the NAS fails at the very last stage of the process.
File copy from NAS to tablet is working, though, but it's an extra step.
ps: it wasn't the app/NAS but some router/wlan misconfig or incompatibility
works flawless with another one (which happens to be much newer)
-
I had to disable the problematic shared folder to get it working. Now I need to go rename the folders/files inside of it. I always wondered why Macs do that... I remember trying to transfer lots of files to an OS9 machine back in the day but Fetch would crash instantly. I figured out that I needed to rename the files. OS9 doesn't like long filenames or ones with weird characters, is the problem, I think.
-
http://www.comentum.com/File-Systems-HFS-FAT-UFS.html
max characters of 31 according to this chart
-
Same here with renaming, though no real offenders, but some files were renamed.
Added a shortcut to the Chooser to avoid entering the IP every time (unless you automount the selected drive/shared folder) by modifying the Appleshare extension with ResEdit.
Replaced the empty text entry in dialog -904 by the IP string.
IOS transfers of single files work nicely, but directories are pretty wiered.
Tested a tree which was transferred but entirely hidden from outside the respective IOS app.
There's some difference between the Synology DSFiles and DS Cloud apps, the latter is more convenient as it skips the login which DSFile always presents, but hides the folders.
Anyway, zipped folders transfer retaining their structure, so it's a workable solution.
-
I've been using my Synology NAS for almost an entire year now with my OS8.6 systems. It works without a hitch. I don't have to turn on external SCSI drives or use zip disks or burn CDRs or anything. Just go to Chooser, select Appleshare, connect to my NAS's AFP server, transfer files, done. A NAS was probably the best investment I've ever made for my oldschool Macs. I'm able to store my Pro Tools sessions and midi project files and transfer between studio rooms, just like I'm storing it on an external drive and taking it into another room. I was scared to use it at first since I thought it'd screw with the files like DH was pointing out (the OSX AFP stuff), but nope, this thing rocks.
The only problem I have with the AFP-NAS method is that it's slower than usual since the 9600's built-in ethernet gives me only 1MB/sec at its maximum. I had a better, faster ethernet card in my 9600 but couldn't get it to work. I'm not sure I even want to sacrifice a PCI slot on my 9600 anyway, but I do have a free slot in there.
-
I've been using NAS drives for a few years with OS9 also and haven't had any problems. My Netgear ReadyNAS was the fastest over AFP, my Ausustor 1004T (which is newer) is somewhat slower but just as reliable. They have been the best method for me transferring between machines, storing files etc.
-
Same here with renaming, though no real offenders, but some files were renamed.
Added a shortcut to the Chooser to avoid entering the IP every time (unless you automount the selected drive/shared folder) by modifying the Appleshare extension with ResEdit.
Replaced the empty text entry in dialog -904 by the IP string.
IOS transfers of single files work nicely, but directories are pretty wiered.
Tested a tree which was transferred but entirely hidden from outside the respective IOS app.
There's some difference between the Synology DSFiles and DS Cloud apps, the latter is more convenient as it skips the login which DSFile always presents, but hides the folders.
Anyway, zipped folders transfer retaining their structure, so it's a workable solution.
Can you give more detailed instructions for editing the chooser to have an IP already in the field? That’d be an awesome tweak. I wish I could just select a menu item and BAM, the NAS is mounted.
-
By the way, for people connecting to a NAS, don you find that every time you go to your server that the icons are switched back to the icon view? I have to switch it back to the list view every single time I connect. MacOS seems to remember folder settings locally but must reset them for network folders or something.
-
that should only happen when it is not HFS?
-
So Mac OS can’t remember settings for anything other than HFS/+? The Synology is btrfs so that’s probably gonna why if so. I connect using AFP of course but now this has me wondering how a foreign file system can be read by my Macs. Unless it works differently than that.
-
re. View format when file sharing - The client follows whatever is set on the host.
So if you want list view, set the folder on the host to list view.
Similarly, if using icon view, and find yourself repositioning icons each session - you need to reposition them directly on the host.
-
Im not even sure I can do that on a synology. I’m gonna investigate and find out. File Station is what we use to browse files on it. Thanks for the tip, gonna investigate.
-
So Mac OS can’t remember settings for anything other than HFS/+? The Synology is btrfs so that’s probably gonna why if so. I connect using AFP of course but now this has me wondering how a foreign file system can be read by my Macs. Unless it works differently than that.
that a filebrowser looks like the finder doestn mean it wouldnt be an upload. but actually i would expect that a proper network browser (that includes the finder in 9 and x) can still remember all settings.
-
I contacted synology and they said that the views settings is a feature of Finder, not the Synology NAS. I guess Finder doesn’t remember the settings for network folders so I’m kind of stuck with the icon view coming up every time.