Author Topic: Mac files on a new NAS  (Read 1430 times)

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Mac files on a new NAS
« 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.

Offline devils_advisor

  • Platinum Member
  • *****
  • Posts: 645
Re: Mac files on a new NAS
« Reply #1 on: March 09, 2017, 01:26:40 AM »
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.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 643
Re: Mac files on a new NAS
« Reply #2 on: March 09, 2017, 06:14:09 AM »
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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Mac files on a new NAS
« Reply #3 on: March 12, 2017, 03:09:55 PM »
Worst comes to worst I'll just store backups as bin files.

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #4 on: March 25, 2017, 12:35:50 PM »
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.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Resource forks and Stuffit Deluxe
« Reply #5 on: July 28, 2017, 10:17:11 PM »
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.

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Mac files on a new NAS
« Reply #6 on: July 28, 2017, 10:21:42 PM »
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?

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Resource forks and Stuffit Deluxe
« Reply #7 on: July 29, 2017, 12:02:12 PM »
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.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Resource forks and Stuffit Deluxe
« Reply #8 on: July 29, 2017, 12:31:39 PM »
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.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Resource forks and Stuffit Deluxe
« Reply #9 on: July 29, 2017, 12:57:03 PM »
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
« Last Edit: July 29, 2017, 01:20:39 PM by DieHard »

Offline GaryN

  • Platinum Member
  • *****
  • Posts: 665
  • active member
Re: Resource forks and Stuffit Deluxe
« Reply #10 on: July 29, 2017, 06:30:09 PM »
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…

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Resource forks and Stuffit Deluxe
« Reply #11 on: July 29, 2017, 07:35:13 PM »
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-

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Resource forks and Stuffit Deluxe
« Reply #12 on: July 31, 2017, 10:02:00 AM »
From Gary...
Quote
Yeah…What HE said…

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

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Resource forks and Stuffit Deluxe
« Reply #13 on: July 31, 2017, 11:12:22 AM »
Quote
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: 
Quote
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...

Quote
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:
Quote
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 ?
« Last Edit: July 31, 2017, 11:33:45 AM by DieHard »

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Mac files on a new NAS
« Reply #14 on: July 31, 2017, 11:42:44 AM »
Related Info:
Quote
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

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #15 on: July 31, 2017, 03:33:40 PM »
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.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Mac files on a new NAS
« Reply #16 on: July 31, 2017, 08:23:34 PM »
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...

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Mac files on a new NAS
« Reply #17 on: August 01, 2017, 03:06:17 PM »
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
Quote
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)

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #18 on: August 01, 2017, 06:57:02 PM »
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)

"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1232
Re: Mac files on a new NAS
« Reply #19 on: August 02, 2017, 11:44:27 AM »
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.

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Mac files on a new NAS
« Reply #20 on: August 02, 2017, 12:15:08 PM »
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.

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #21 on: August 02, 2017, 08:23:30 PM »
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.

Quote
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?
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline macStuff

  • Enthusiast
  • **
  • Posts: 44
  • New Member
Re: Mac files on a new NAS
« Reply #22 on: August 07, 2017, 03:23:11 PM »
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...
« Last Edit: August 07, 2017, 03:54:59 PM by macStuff »

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #23 on: August 07, 2017, 07:15:26 PM »
using a PC as fileserver will eat up a lot of household electricity ;)
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline macStuff

  • Enthusiast
  • **
  • Posts: 44
  • New Member
Re: Mac files on a new NAS
« Reply #24 on: August 07, 2017, 10:06:08 PM »
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!

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1569
  • new to the forums
Re: Mac files on a new NAS
« Reply #25 on: August 08, 2017, 04:03:42 AM »
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.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline macStuff

  • Enthusiast
  • **
  • Posts: 44
  • New Member
Re: Mac files on a new NAS
« Reply #26 on: August 09, 2017, 08:29:26 AM »
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!
« Last Edit: August 09, 2017, 08:56:12 AM by macStuff »

Offline devils_advisor

  • Platinum Member
  • *****
  • Posts: 645
Re: Mac files on a new NAS
« Reply #27 on: October 15, 2017, 09:31:44 AM »
<a href="http://www.youtube.com/watch?v=GgdwneSi5Qg" target="_blank">http://www.youtube.com/watch?v=GgdwneSi5Qg</a>

Offline Syntho

  • Platinum Member
  • *****
  • Posts: 904
Re: Mac files on a new NAS
« Reply #28 on: October 16, 2017, 06:34:58 PM »
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.

Offline devils_advisor

  • Platinum Member
  • *****
  • Posts: 645
Re: Mac files on a new NAS
« Reply #29 on: October 17, 2017, 01:16:59 AM »
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