Network Drive

[RPCia]

I do know it is bad to open a shared file over a network. But is it also bad to open a single user file on a network drive?

I have an employee who has 15 files that she has on her desktop and uses but she wants them on the server so they are backed up with everything else. I do not want to load these 15 files on the fmserver because my # of fies is already over 100 and I do not want to host more files if they are only going to be used by 1 person every once in a while.

Would it be safe to store the files on the fileServer and allow her to open them as single user?

The FileServer is a Windows 2003 SBS, the FMserver is version 5.5 on a Windows 2003 Std Server and the client in question is running Version 6 on Windows 2000.

Thanks

[Ender]

No, it's really not recommended to house FileMaker files on any shared drive. Not only does it risk the files to get opened from multiple clients, but in the case of opening the files over the network, it will perform poorly and if the network connection fails, could still lead to corruption.

Perhaps the user could copy the files to a network volume as a backup solution, keeping the working copies on the local hard drive. I don't know Windows, but I believe there are backup utilites and scripts that could be run to automate backing up over the network or to a network volume.

[Steven H. Blackwell]

My advice to you is to put these files on FileMaker Server.

Steven

[RPCia]

Thanks for your replies. It seems my initial thought was correct the risks simply outweigh the rewards in this situation.

Thank you both.

[wjmartin]

I have this exact situation too - I put the files on a share point available to only this user (to prevent multiple opening of the same file) and made sure the connection was fast (1000base) and it all works fine.

The share point is backed up regularly so even if a file were to get corrupted (which has never happened) , I can easily rewind to a good state.

For a low use file that needs assured backup this method works fine for me

[Ender]

I suggest you re-read this thread.

[wjmartin]

I have re-read it - and I am still doing it and it works fine!

FM does not care where the file is as long as it is accessable - the only "risk" is that the file becomes inaccessable through a network problem - that could corrupt the file ok - but in this situation (occasional use of small FM files) I see the risk as entirely acceptable because a) network problems rarely ever happen, and the files are backed up incrementally every hour.

The benefit is that I know those files are safely wrapped up in our automated backup strategy and not dependant on an operator remembering to manually copy them (which we all know is forgotten the day before their machine fails!)

[Genx]

Isnt a once every hour backup a bit excessive. I mean if your file gets to around 30 mb which is pretty average with data... thats 262.8GB a year.

[Ender]

You may not have had problems yet, but sharing files via OS file sharing is a common cause of corruption. And if your backups are created automatically while users have those files open, then there's a good chance the backups will damaged (backups of open files are not reliable.)

If you need to host files to different users, and an automated backup is important, then FileMaker Server is the most reliable way to go.

[Ted S]

Interesting thread.

I have always been under the assumption that the risk with network sharing doesn't come from the simple act of enabling sharing. I thought that the true risk occurs when more than one (1) user actually connects to the shared file at the same time. In other words, my impression is that sharing is okay but only if you can ensure that only one user is connected at a time. This single user sharing is possible in a Windows network, Mac I don't know about.

Maybe I'm all wet and sharing via the OS is a bad idea under all circumstances. Anyone know for sure?

[Steven H. Blackwell]

Do [color:red]not, repeat, not enable OS level file sharing. It will, sooner or sooner, damage your files.

Steven

[wjmartin]

Guys! - Relax - it is a simple requirement with a simple solution that works fine for me! - stop looking for pitfalls that dont relate to THIS scenario!

The two big risks are covered (network and users) and I can sleep at night knowing the stuff is backed up!

For me it is a much lesser evil than being told by my gaumless user that they have not made a secure copy of the originals for months - because that is exactly what happened and that is why I went with this solution.

And to answer some specific comment - the files are very small and only occasionally modified so the backup size is not a problem - and my network is very very stable so I have never had a corruption in the 6 months or so of doing this.

Edited May 17, 2006 by Guest

[Ender]

:bang:

[Vaughan]

Hi wjmartin

For many, many freelance developers, fixing up and rebuilding FMP databases that have been corrupted through OS file sharing is bread-and-butter business!

The corruption is always "death by a thousand cuts" that occurs over many months and years, not a single big-bang incident. Invariably, none of the backups are ever useful because they are themselves full of border-line data corruption; any that are old enough to be clean are probably not going to be useful anyway, because the data and/or structure is obsolete. Either way, it's a full rebuild-from-scratch to get going again which ends up costing more than doing the job right in the first place.

[wjmartin]

Thanks Vaughan that is the first 'supported argument' so far in this thread! Interesting that so many are prepared to quote the scripture without expalining (or knowing?!) the reasons why.

I have run "Recover" on all the files and not discovered any problems - but I accept what you say - a creeping long term corruption was not a risk I had identified or covered for.

[Genx]

Running "recover" isn't a great idea, even FM say so. It uses the so called "brute-force" to completely rebuild the file, this includes deleting corrupted objects etc. The only thing it should ever really be used for is trying to get the data out of a corrupted file.

~Genx

[Søren Dyhr]

without expalining (or knowing?!) the reasons why

Well here is one:

Sharing the FM folder that the files reside in can cause a FM crash. My understanding is that the cause is the very complex interaction between the TCP/IP network layer (typically this occurs only in TCP/IP), OS file sharing interaction with the OS security, interaction between FMP file data requests using the TCP/IP stack and the OS security trying to prevent inappropriate file access of a shared volume.

Scenario;

1. The folder in which the FM files reside is shared by the OS.

2. FM is sharing the file(s) using the selected protocol.

3. The OS is charged with preventing inappropriate access of the files on the hard drive (but the FMP program is running locally!).

4. Now the OS detects a request for data using a file access over the network, since the file is in a shared volume the OS thinks it is supposed to read/write to the file it tries to authenticate the access. However, there is no 'real' network access going on and there is no user interface and (remember FMP is running locally) no way for FMP to tell the OS the access is OK. The OS gets confused and crashes FMP. Since FMP has its own sharing stack using the protocol the OS shouldn't get in the way, but if the folder is shared the OS will try to authenticate file access privileges. The problem seems to occur because the OS level security thinks the network request for file 'data' should be authenticated even though it came through the FMP stack and the local copy of FM will do the actual file access. Go figure.”

...snipped from here!

--sd

[xochi]

Sharing the FM folder that the files reside in can cause a FM crash. My understanding is that the cause is the very complex interaction between the TCP/IP network layer (typically this occurs only in TCP/IP), OS file sharing interaction with the OS security, interaction between FMP file data requests using the TCP/IP stack and the OS security trying to prevent inappropriate file access of a shared volume.

Scenario;

1. The folder in which the FM files reside is shared by the OS.

2. FM is sharing the file(s) using the selected protocol.

3. The OS is charged with preventing inappropriate access of the files on the hard drive (but the FMP program is running locally!).

4. Now the OS detects a request for data using a file access over the network, since the file is in a shared volume the OS thinks it is supposed to read/write to the file it tries to authenticate the access. However, there is no 'real' network access going on and there is no user interface and (remember FMP is running locally) no way for FMP to tell the OS the access is OK. The OS gets confused and crashes FMP. Since FMP has its own sharing stack using the protocol the OS shouldn't get in the way, but if the folder is shared the OS will try to authenticate file access privileges. The problem seems to occur because the OS level security thinks the network request for file 'data' should be authenticated even though it came through the FMP stack and the local copy of FM will do the actual file access. Go figure.”

--sd

[Vaughan]

"Thanks Vaughan that is the first 'supported argument' so far in this thread!"

LOL.

Only wanna-bees like me have to support their arguments, usually by providing authoritive quotes from dudes like Mr Steven H. Blackwell. :

[Søren Dyhr]

To be polite, that's voodoo b*llsh*t, written by someone who doesn't know a thing about networking or OSs.

Fair enough! I had some reservations about the ambiguous choise of words, as well. Further more did the text deal with 5.5 - but when we are at it ...how BS is this then:

Files you want to share in FileMaker have to be set to multi-user (not the default setting) and may not be located in a shared volume. Operating System file sharing must be turned off, users have to access the file through the HOST procedure. This is a very big and very important difference. One that is difficult for MS oriented staff to understand because it is the exact opposite of all Microsoft file sharing rules.

--sd

[wjmartin]

This has become almost philosophical - there seems to be two streams of thought

1) Purist - It is not correct, therefore dont do it

2) Realist - It works, that means its ok

In answer to the original question that sparked this thread, if you are a purist dont do it. I simply put my oar in in defence of the realists - my environment does not allow for purity, I work with that heady mixture of computers and humans - and we all know as soon as you put a human in the equation, perfection goes out the window - I may be working against the computer, but I am deliberately doing so in support of the much less reliable human!

[Wim Decorte]

"it works" does not mean it works OK. Like vaughan mentioned before it can be "death by a thousand cuts". And it very frequently is. But there are exceptions.

If you can be totally sure that only FMS can access the network share, then you won't have any problems with OS sharing. But a typical situation goes like this (and I've seem this happen more times than I care to count - I make a good dollar rectifying these scenarios):

- OS sharing is set up and restrictions are OK

- over time, admin leaves or a hires an assistant who starts standardizing all shares (allowing more people in) or changing OS privileges on a parent level that propagates down,...

- leads to people suddenly being able to move/delete/open the live hosted files

- leads to corrupted files with no known good backups...

Putting the FMS files on a network volume away from FMS: typically (but again not always) this makes the whole setup more vulnerable. And to achieve the best possible uptime you normally want to eliminate as many vulnerabilities as you can. No black or white here: a sturdy NAS is better than a crappy hard disk, and vice versa.

Which is why the rule-of-thumb & best practice is "don't use OS sharing". At the very least understand the best practices, see the risks in not following them and document the hell out of why you're doing it so that anyone who comes after you can follow the reasoning and check to see if it still valid.

Edited May 19, 2006 by Guest
spelling mistake

[Fenton]

I would like to point out that before you dismiss the comments by Jimmy Jones you should know something about him. I don't know his present position at FileMaker, but he has stated on other mailing lists that he was in charge of dealing with corrupted files for several years. This was a while ago, but I don't think that aspect of FileMaker has changed much (perhaps it should, but that's a different question).

He has also stated that there is no known way to positively ascertain that a file which is not behaving badly is free of corruption. So, the statement that it must be OK because it works is not true. It might be, it might not.

Most IT guys prefer file sharing on, because that is what they know, it makes their job easier, and it appears to cost less. FileMaker developers who don't do IT (such as myself, or have had bad experiences with this) prefer it off. I always tell my clients about this. Many of them, especially the larger businesses with inhouse IT, tend to ignore me. So be it. I keep a clone of their files, and am willing to be paid to restore their files. Restoring good copies of the files usually costs as much as separating FileMaker properly in the first place, especially since it will likely happen again unless they change their setup.

[xochi]

We shouldn't really care who Jimmy Jones is, what matters are his explanations. His explanation, (which it's pretty clear he doesn't actually understand), if you read it carefully, is most likely a description of two people accessing the same file simultaneously (the first one opening as a "local" file via a network share, and the second one opening it via TCP hosting using "open remote...").

I know a lot about filesystems & networking, there is no conceivable explanation I can come up with for how a properly set up & functioning network share could damage the file.

That being said, people are human and make mistakes, and I can totally agree with the sentiment that even if you put a "do not push" sign on the self-destruct button, someone may push it anyway.

I think people should use Filemaker Server -- in my experience, it can generally handle a Client crashing or disconnecting with zero problems, and it can perform "live" backups safely.

Opening a file in single-user mode is way more dangerous (whether on a network share or a local drive). If the client crashes, you might corrupt it.

Here's a twist -- what about using FileMaker Server, but storing the file on a network share? Kaboom?

[Ted S]

xochi,

We shouldn't really care who Jimmy Jones is, what matters are his explanations

I'm going to disagree with you on this one point. Lets say a pilot witnesses a plane crash as does an accountant. Common sense would say that you should give more weight to the pilot's story than that of the accountant because aviation is the pilot's business and area of expertise. This doesn't mean that without a shadow of a doubt that the pilot's account of the crash is absolutely true and the accountant's verson is unquestionably wrong. It just means that in most instances the pilot is more likely to be correct.

If Jimmy Jones is indeed a FileMaker employee, and I don't personally know anything about this guy, then I would tend to trust his take over that of an unknown person posting on a web forum.

That being said, I think we all know plenty of people who should be experts in their area but clearly aren't. What you are saying makes some sense to me but I am not any sort of authority in this area.

I'm enjoying the airing of the different opinions.

[stanley]

Here's a twist -- what about using FileMaker Server, but storing the file on a network share? Kaboom?

Kaboom, indeed!

I had a client do this once. I had set up the system (FMS 5) in the standard secure non-shared manner, and someone (apparently a ghost, because nobody in the office admitted it) decided to turn the FileMaker Server into an iTunes server, and in the process turned on file-sharing, even though it wasn't necessary. ONE DAY LATER the whole system imploded. All 22 .fp5 files were corrupted to the point of not even opening.

I made a lot of money that week.

-Stanley