Bridget wrote:
We changed the default due to problems with NT backup software handling snapshots badly.
Actually, that was only one reason. It was also confusing to Office's "find fast", xcopy, explorer, etc.
Apart from the option Bridget mentioned, you should understand that you can enter the ~snapsht from any open dialog; you just have to explicitly name it. You can use it anywhere you can specify a path. (Also, ".snapshot" and "~snapshot" are valid names from NT.)
Mark Muhlestein -- mmm@netapp.com
We use NFS and CIFS on our toasters. Since upgrading to 5.1.2, our PC clients no longer see the ~snapshot directories. (This is the .snapshot directory on unix clients.)
Is there a fix? This is disconcerting. Or should I say broken?
Quoth Mark Muhlestein:
We changed the default due to problems with NT backup software handling snapshots badly.
Actually, that was only one reason. It was also confusing to Office's "find fast", xcopy, explorer, etc.
I find it disgusting that NetApp caters to Microsoft's ineptitude.
Regards,
David K. Drum david@more.net
On Thu, 5 Nov 1998, David Drum wrote:
Quoth Mark Muhlestein:
We changed the default due to problems with NT backup software handling snapshots badly.
Actually, that was only one reason. It was also confusing to Office's "find fast", xcopy, explorer, etc.
I find it disgusting that NetApp caters to Microsoft's ineptitude.
Me too. At least in the traditional human fashion, Netapp and countless others are showing us in simple, easy to swallow caplets, what *NOT* to *EVER* do, and why not to do it. Just learn the options and their defaults, and make your choice! :) How much more convenient could it be?
<dtm wanders off into the world, to become adored, cherished, and famed with his upcoming paper on how to fix Microsoft with the fabulous FDISK Suite(tm)>
Wouldn't this be solved if ~snapshot appeared as a shortcut in CIFS, and as a symbolic link in NFS?
I think the default is right... the default should be the option that doesn't mess with any software. Turn it on at your own risk.
--tal
In article 364225F4.47D356C@dnrc.bell-labs.com, you write: |> |> Wouldn't this be solved if ~snapshot appeared as a shortcut in CIFS, and |> as a symbolic link in NFS?
A symbolic link to what? Something that exists, so the "problem" is still there.
Mind you, I'm not exactly sure what the problem is, as the .snapshot directory only *has* to appear at mountpoints (see below) and that is the default (I think - this is for NFS). Is the problem that you have separate mountpoints for individual users HOME directories?
It would be even better if you could get rid of the one at the mountpoint as well, thne find would never have a problem (but you could still get to .snapshot by name - it becomes and entry you get if you ask for it, but not an entry when you read the directoiry contents). However, when I did turn them off (long time ago) I found that df at the NetApp console would no longer give me any snapshot info. Anyone know whether that bug/feature has been fixed (it was reported...)?
Also, one thing that I would like to see changed (if it makes sense) is for the NetApp servers to return different inodes for snapshot entries (OR in teh snapshot number at the top-end?). The reason for this is that some versions (egL GNU) of diff seem to check fs/inode info, and if they find they are the same they don't bother to do any diff'ing....
Lack Mr G M wrote:
In article 364225F4.47D356C@dnrc.bell-labs.com, you write: |> |> Wouldn't this be solved if ~snapshot appeared as a shortcut in CIFS, and |> as a symbolic link in NFS?
A symbolic link to what? Something that exists, so the "problem" is still there.
No, because every program(1) in UNIX knows to skip symbolic links when traversing trees of files. I presume that the same is true for shortcuts in CIFS otherwise MS-Office's fastfind and other programs would have the same problems.
In fact, I wonder if the solution here is to turn off visible .snapshot and ~snapshot at the mointpoints and put symbolic links in the user's directory that are SNAPSHOT -> .snapshot. Or, if NetApp could have these appear as symlinks/shortcuts that would solve the problem.
--tal
(1) Every program except "cp -r", because it hasn't been updated in decades; and "find -follow", because it is supposed to follow symbolic links.
In article 364309A3.51B00C64@dnrc.bell-labs.com, you write: |> |> > A symbolic link to what? Something that exists, so the "problem" is |> > still there. |> |> No, because every program(1) in UNIX knows to skip symbolic links when |> traversing trees of files.
I was actually referring to the target of the symlink rather than the symlink itself.
The issue seems to be getting a little cloudy though, as some people seem to want a .snapshot appearing everywhere, but not be auto-traversed, some don't want it everywhere (including those of us who don't want it at the mountpoints).
No, because every program(1) in UNIX knows to skip symbolic links when traversing trees of files. I presume that the same is true for shortcuts in CIFS otherwise MS-Office's fastfind and other programs would have the same problems.
Shortcuts are just ordinary files that the explorer treats specially; Win32 has no notion of symbolic links (although NT 5.0^H^H^H^H^H^HWindows 2000 may have it as one side-effect of the reparse points stuff, etc.).
As such (as I think others have noted), Win32 apps have no way to avoid going down a symlink, as they have no idea that something *is* a symlink.
-
Dan Bethe -
David Drum -
gml4410＠ggr.co.uk -
guy＠netapp.com -
Mark Muhlestein -
Tom Limoncelli