Subject: "Another process changed the volume during the search..."

From: "Chris Garrigues" <[email-masked]>
Date: Wed, 07 Feb 2001 17:02:46 -0600

One of the clients I've set up using netatalk is having a problem where when 
he attempts to use Sherlock to search a netatalk volume, he gets an alert with 
this message:

	Unable to search the volume "WCFileServer"
	Another process changed the volume during the search.
	Please wait for the process to finish and try again.

He's running 9.0.  I assume that another user updated something during his 
search.  Am I right in this assumption?  Is there anything I can do about this?

Chris

-- 
Chris Garrigues                 http://www.DeepEddy.Com/~cwg/
virCIO                          http://www.virCIO.Com
4314 Avenue C                   
Austin, TX  78751-3709		+1 512 374 0500

  My email address is an experiment in SPAM elimination.  For an
  explanation of what we're doing, see http://www.DeepEddy.Com/tms.html 

    Nobody ever got fired for buying Microsoft,
      but they could get fired for relying on Microsoft.

---

From: Walt Reed <[email-masked]>
Date: Wed, 07 Feb 2001 16:06:54 -0800

> search.  Am I right in this assumption?  Is there anything I can do about this?

you neglect to mention what processes might be using the volume:  apache, samba,
wuftp, nfs, backup software?
are users connecting through ftp via bbedit?  do users telnet to the machine?  how
many users?

do any of the other users @ the location experience similar problems?  is the user
a "perpetual problem" user?  how many other programs is the user running @ the
same time?

i'm just trying to get an idea of how many variables you are dealing with.  also,
i'd update this person to 9.0.4, i've noticed better network performance.

if, in fact, you are right and another user is changing the files and interfering
w/ the search, i think i'd try writing an applescript that mounts the volume and
then indexes it @ night when no one could bother it, then shuts down the machine.
once sherlock has it indexed, it should be able to search easier.

hope that helps,

walt reed
systems administrator
terrascope

---

From: "Chris Garrigues" <[email-masked]>
Date: Wed, 07 Feb 2001 18:36:10 -0600

> From:  Walt Reed <[email-masked]>
> Date:  Wed, 07 Feb 2001 16:06:54 -0800
>
> Chris Garrigues wrote:
> 

None of the above.  This particular machine is only used by atalk users.  
Backup software wasn't running at the time.  apache is on the system, but it's 
home is in a different part of the filesystem.  Samba is also running, but 
there are no PCs on that particular site.  telnet is disabled and the only 
people who have ssh are myself and my partner, neither of whom were logged in.

> a "perpetual problem" user?  how many other programs is the user running @ the

He's the most cluefull user at that particular client.  The other users all pass
their issues through him.  I'll check with him and see if anyone else is having 
the problem.

> i'd update this person to 9.0.4, i've noticed better network performance.

I think he's actually using 9.0.4, but I'll make sure about that as well.

> once sherlock has it indexed, it should be able to search easier.

How do you do that?  Sherlock/Find/Index Volumes doesn't list the server and I 
read in the archive that Apple disabled the ability to build indexes over the 
network.

(For some context, I'm primarily a Unix guy but i know my way around a Mac 
fairly well.  I don't do windows.)

Chris

---

From: Walt Reed <[email-masked]>
Date: Wed, 07 Feb 2001 17:53:36 -0800

> fairly well.  I don't do windows.)

hmm.. i thought you could do an index like that, but it seems you can't anymore, that's
too bad.
found this in the help menu:
"Mounted servers, CD-ROM discs, and read-only disks...do not appear in the Index
Volumes window."  it goes on to say that you can index it "directly on the shared
volume", which i assume means only if it's a mac, and directly from it's console.  you
can get the contextual menu to give you the option (hold down the "ctrl" and click on
the volume from the finder) to index, but it doesn't work.  sorry about that.

i'd still check his system & make sure he's running 9.0.4.  turn off samba if you
aren't using it, or at least turn it off for now, to eliminate it from the equation.
is the problem intermitant?  i tried to do a sherlock search here (i did 2 @ the same
time from different machines) and found it slow, but it worked, and my users telnet,
ftp, samba, etc.  do your users open files directly from the server, or do they use
local copies and update the server (or is there a version control software running)?
i'm wondering if a file could be getting locked or updated as you said.  one of the
most insidious problems i've had to deal w/ is users trying to include fonts off the
server in adobe type manager rather than copying them to the local drive, resulting in
weird startup problems, but that's a whole 'nother issue...

other than that, all i can think of is to make sure nfs isn't somehow on.  i know it
can lock files that are in use.

will keep looking into it.

walt reed

---

From: "Chris Garrigues" <[email-masked]>
Date: Thu, 08 Feb 2001 09:20:43 -0600

> Date:  Wed, 07 Feb 2001 17:53:36 -0800
>

Thanks.  More data:  Everybody there is having this problem. About half of the 
machines are running 9.1 and the other half will be doing so as well soon.

I've just stopped samba and nfs and have asked him to let me know if it helps.

They do open files directly on the server.  I'm not sure exactly what 
applications they use, but they're an advertising firm if that gives a clue.  
This problem didn't occur when they were using a Mac server.

I'll post again when I know if turning off samba and nfs helped.

Chris

---

From: "Chris Garrigues" <[email-masked]>
Date: Tue, 13 Feb 2001 15:16:10 -0600

> From:  "Chris Garrigues" <[email-masked]>
> Date:  Thu, 08 Feb 2001 09:20:43 -0600
>

Turns out that it was nfslock causing the problem.  We use nfs little enough 
that I'm going to turn off nfslock until I get screwed by not having a lock 
daemon, then I'll worry about how to fix it.

Chris

---

From: Chris Harwell <[email-masked]>
Date: Tue, 13 Feb 2001 17:55:06 -0500 (EST)

hi,

When a file with a long file name is created in linux (in this case via scp)
it doesn't show up over atalk. If a file with a long name is created over
netatlk it does.

Anyway around this?

thanks,
-- 
chris
[email-masked]

---

From: Cliff Crawford <[email-masked]>
Date: Wed, 14 Feb 2001 19:11:32 -0500

> it doesn't show up over atalk. If a file with a long name is created over

Not really, Mac OS has a 32-character limit on filenames.  So you have to
make sure the filenames are shorter than that for them to show up.

(If the cutoff you're experiencing really is at 27 characters, like it
says in the subject, and not 32, then I guess it's not the Mac OS
filename limit that's causing it..I don't know what could be wrong in
that case.)

-- 
Cliff Crawford                 http://www.people.cornell.edu/pages/cjc26/
"huh?  Are you all there?  You missing some key parts up there?  Becoming  
a English major or an minor?   Do you need a annual report?  Are you slow
today, eh?  Did someone sever you parietal lobe?" - Mark

---

From: Matthew Geier <[email-masked]>
Date: Thu, 15 Feb 2001 12:58:41 +1100

> filename limit that's causing it..I don't know what could be wrong in

27 + '.' + 'M$ style 3 letter extension' ?, thats 31 characters.... 

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University

---

From: Carsten Neumann <[email-masked]>
Date: Thu, 15 Feb 2001 11:25:23 +0100

> 27 + '.' + 'M$ style 3 letter extension' ?, thats 31 characters.... 

Feel like lying naked under the table of a pub - people tumbling around,
kicking my balls.

Are we going MessDos?!

Filenames aren't "suffixed" by afpd when transferred to a Mac.
If so: why? There would be no need. Netatalk is not samba!

I just checked this: the limit is at 31 chars (like MacOS).
Are you using a different version of natatalk?
I'm using 1.4b2+asun2.1.3.

Regards

	Carsten

---

From: Bill Moran <[email-masked]>
Date: Thu, 15 Feb 2001 08:52:04 +0000

> Feel like lying naked under the table of a pub - people tumbling around,

To each his own.

> If so: why? There would be no need. Netatalk is not samba!

No, but if samba were creating the files, it would look on the Mac like
the "filename" (the part before the dot) was limited to 27 chars.

-Bill

---

From: Danny Sauer <[email-masked]>
Date: Thu, 15 Feb 2001 09:36:59 -0600

> > Feel like lying naked under the table of a pub - people tumbling around,

Eeek.

> the "filename" (the part before the dot) was limited to 27 chars.

You mean if the files were created on windows with "hide registered file types"
activated, then the windows user would only see 27 chars, but the mac and *nix
sides would see the dot and extension that windows creates behind the scenes,
pushing the real filename over the 31 char limit.  Right?

The problem here, as usual, likely lies with windows. :)

--Danny

---

From: Bill Moran <[email-masked]>
Date: Thu, 15 Feb 2001 11:05:10 +0000

> pushing the real filename over the 31 char limit.  Right?

No, when Win makes the file it makes fname.ext - always. The setting for
"hide registered file types" does nothing to change the filename. It
only affects the way explorer _displays_ the name.
However ... If you're creating files with windows you will _need_ a file
extension so windows knows what the file is (since it doesn't use magic
like UN*X or a resource fork like Mac) Therefore, the maximum length of
the _filename_ part of the name ... if you create it from windows and
want it to be accessible from the Mac is 27 characters.
If you consider the extension part of the filename, then the max is 31
characters.
It's not a technical thing, it's a matter of how you look at it.

> The problem here, as usual, likely lies with windows. :)

Sorry, but I don't consider this a "problem". I'm not a windows advocate
or anything (I use nothing but FreeBSD, personally) but the decision to
use file extensions to identify file types is no different than Apple's
decision to use resource forks for the same purpose. The issue is simply
the incompatibility in the way this is handled between different
systems.
I do have other complaints about this approach, however. If the file
extension is so important, then the "." should be a reserved character
in Windows and should not be a legal part of the filename. If Micros~1
had thought it through and made the dot illegal except to create file
extensions, this rash of "viruses" (as the media lazily and inaccurately
calls them) wouldn't be occurring because a file like
"kornakova.jpg.vbs" would be an illegal filename and couldn't fool
people.
That, however, is off topic.

-Bill