Re: [Netatalk-admins] Photoshop, Disappearing Files, and Dropped connections

[David T. <dti...@ad...>]

Nigel,
You were correct. There is a .DS_Store file and a .AppleDouble directory. I 
don't suppose there is a way to make them aware of each other is there? In 
general, to my dismay, I am finding Samba to be a more reliable server 
daemon than netatalk for the kinds of things my OS X clients are doing 
(lots of Illustrator and Photoshop files). In particular, Adobe 
Illustrator, Netatalk, and OS X don't work well together. If an OS X client 
attaches to the server via netatalk and then launches Illustrator and goes 
to "File" "Open", the OS crashes and the machine needs to be turned off and 
then turned back on. If Illustrator is open before attaching to the server, 
there seems to be less of a problem but the end users are nervous about 
losing work. I thing netatalk running IP only is a cleaner connection in 
terms of traffic than Samba but these particular issues need to get 
resolved for reliability. I know Photoshop has historically been a problem. 
It used to be that users had to have write rights to the root of a volume 
if you wanted to save directly to the server. That was supposedly fixed in 
either Photoshop 5.0 or 5.5 interacting with ApplShare IP servers but they 
are a slightly different kettle of fish from a Unix based solution running 
netatalk.
Dave

At 11:11 AM 2/5/2003 +1100, Nigel Pegram wrote:
>Dear Dave,
>
>I'm not really familiar with Samba, but would suggest that Samba is not 
>creating any resource information, or (more likely if using OSX client) is 
>creating OSX style resource info. This would mean that you have the 
>resource information stored differently for each type of save. OSX has 
>.DS_Store files, from memory, netatalk uses .AppleDouble.
>
>Each type of daemon would look for its respective type of resource info. 
>Using the correct file extensions might help somewhat.
>
>HTH
>Nigel
>
>On Tuesday, February 4, 2003, at 12:33 AM, David Tisdell wrote:
>
>>It would seem to me that the OS should be aware that the type and creator 
>>code is there no matter how the connection was established. In some cases,
>>  the files were unusable when they were created with one type of 
>> connction to the server and then a user tried to open them later with 
>> the other type of connection. If you went back to using the connection 
>> that created the file, it worked fine. Any ideas about what is going on 
>> here? Thanks.
>>Dave
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Netatalk-admins mailing list
>Net...@li...
>https://lists.sourceforge.net/lists/listinfo/netatalk-admins