Subject: 8bit chars, no refresh

From: Axel Rose <[email-masked]>
Date: Fri, 27 Apr 2001 12:30:59 +0200

Hello,

I posted two support requests on sourceforge but got no responses
until now.

May I repeat them here on the mailing list:

-1-
no Finder refresh after Unix move

after moving a file by a Unix script to a shared volume it will not 
become visible if the volume is already opened in the Finder. 
If otoh I close cmd-w the volume and reopen the moved file is 
visible immediately. 

scenario: 
pap print 
lpd is configured with :if=<script>: 
<script> moves stdin to a temporary location 
PostScript file is distilled with GhostScript "ps2pdf" 
script moves ready-made PDF to shared location 
now Macs have to wait ages or reopen the volume 

I tried a "touch" on the created files but without success. 

My sample lpd if follows: 
#!/usr/local/bin/perl -w 

my $out = "/tmp/psout$$.ps"; 
open( O, ">$out" ) || die "can't create '$out'\n$!\n"; 
print O while(<STDIN>); 
close O; 

my $tmp = "/tmp/pdf/psout.$$.pdf"; 
my $pdf = "/share/pdf/psout$$.pdf"; 
system( "/usr/local/bin/ps2pdf13 -dPDFSettings=/prepress $out $tmp" ); 
rename( $tmp, $pdf ); 
system( "chmod 777 $pdf" ); 
exit 0; 

Is there a configuration parameter somwhere? 
Is there a workaround to notify Macs of changes in the server Desktop? 
(I'm used to Helios EtherShare where I apply a special move command 
or a Desktop rebuild) 

my system: netatalk-1.5pre6, RH 7.0 

-2-

can't delete files if 8bit chars

I can reproduce the following error on two different 
RedHat 7.0 systems running a fresh install of 1.5-pre6: 

Files with a filename containing 8bit chars can't be 
deleted from the Mac side. 

To reproduce: 
$ perl -e '$file="\212"; open(F,">/share/pdf/$file") or 
die; close F;' 

where /share/pdf is my shared volume 

You will see a file "ä" on the server which can't be 
deleted from the Mac. The Finder will complain and not 
offer a workaround.

---

I would be very grateful for help regarding those issues.

Best regards

Axel Rose

----------------------------------------------------------------------
Axel Rose, Springer & Jacoby Digital GmbH & Co. KG, mailto:[email-masked]
  pub PGP key 1024/A21CB825 E0E4 BC69 E001 96E9  2EFD 86CA 9CA1 AAC5
  "... denn alles, was entsteht, ist wert, daß es zugrunde geht ..."

---

From: Axel Rose <[email-masked]>
Date: Fri, 27 Apr 2001 13:39:29 +0200

Um 12:58 Uhr +0200 27.04.2001, schrieb Mac Conin:
>the first is imho not resolvable. This depends on how a refresh
>of the directories content is initiated.

The commercial products have no problem with this.
I wonder how this works then.

>touch ä
>chmod 755 ä
>chgrp to users or any you want to
>an then the client is capable of deleting the file.

It's not an permission problem.
As "root" I issued
chmod 777 *
checked with ls -l
permissions are set

Still the Mac says
"ä" kann nicht in den papierkorb bewegt
werden, weil das Objekt nicht gefunden wurde.

("ä" can't be moved to the trash because the
object can't be found)

A special bug with my system configuration or
simply because the file was created from Unix?

Axel

---

From: Mac Conin <[email-masked]>
Date: Fri, 27 Apr 2001 13:44:25 +0200

Hmm,

that depends maybe on how you've set the /etc/atalk/AppleVolumes.default
or in the users home directory the .AppleVolumes files.

look at a file generated from a mac on the server.
Does it look like 'ä' or does it a display like :81

-- 
--schnipp-- 

mit freundlichen grüssen

-----------------------------------------------------------
Mac Conin                        EUC Online Service GmbH
Geschäftsführer                  Taubengasse 9
[email-masked]                    D 50676 Koeln
http://www.euc.de                HRB Köln 32038
tel : +49-221-923 27 33          fax : +49-221-239 651
-----------------------------------------------------------
EUC sponsort Clean up Cologne - eine Iniative der IHK Köln,
der Abfallwirtschaftsbetriebe Köln (AWB) und dem
Grünflächenamt der Stadt Köln. http://www.clean-up-cologne.de

---

From: Axel Rose <[email-masked]>
Date: Fri, 27 Apr 2001 14:46:12 +0200

>Does it look like 'ä' or does it a display like :81

It's ':8a' for 'ä'.

Um 13:50 Uhr +0200 27.04.2001, schrieb [email-masked]:
>/data data codepage=maccode.no_recode

Tried that too and it doesn't make a difference. Thanks for the hint.

The solution is clear to me.
Hex 0x8a must be coded in the filename as ':8a'.
This is the same as Helios EtherShare does on non UTF8 volumes,
i.e. solvable

Sorry, I wasn't aware of this and just thought (!) that
netatalk uses a plain filename translation.

Anyway much thanks for the excellent and fast help on this list.

The only problem I have left with netatalk is now the
refresh issue. (o.k. aliases too, but this is quite different)
Do developers work on this? A workaround by perhaps touching a
file would suffice for me.

Sincerely

Axel

---

From: Mac Conin <[email-masked]>
Date: Fri, 27 Apr 2001 15:47:47 +0200

Hmm,

if you find hex-codes on your server, the appropriate codepages
(the translation for the umlauts et. al) are not used or not specified.

look at the AppleVolumes.default

if you declare
/var/lib/nobody "test-drive" codepage:maccode.iso8859-1
alle umlauts are converted correctly

/var/lib/nobody "test-drive" codepage:maccode.iso8859-1 options:nohex
also converts the umlauts but now slash is an illegal character in filenames.

If you use netatalk in conjunction with samba this could be helpful because
mac files with slash ( a legal mac character) are not allowed for the windumps'.

So if you have a file with htat character in a directory and windoze
users want to enter this specific directory they'll get an error reporting
that this directory hasn't been found or any other nonsense.

-- 
--schnipp-- 

mit freundlichen grüssen