Mac files on a new NAS

[Syntho]

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.

[devils_advisor]

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.

[nanopico]

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.

[Syntho]

Worst comes to worst I'll just store backups as bin files.

[IIO]

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.

[Syntho]

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.

[Syntho]

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?

[IIO]

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.

[IIO]

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.

[DieHard]

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

[GaryN]

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…

[Syntho]

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 

[DieHard]

From Gary...

Yeah…What HE said…

LMAO cause that's what I wanted to add after many Gary posts

[DieHard]

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 ?

[DieHard]

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

[IIO]

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.

[Syntho]

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...

[DieHard]

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)

[IIO]

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)

[DieHard]

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.