Samba 2.0.6 on Alpha VMS - file writing problem

[Stephen Hall]

Gents,

Whilst I can't offer any kind of a solution, I can confirm that I'm seeing
exactly the same problem as Robert. ( AlphaServer 1200 5/400 4MB running
OpenVMS V7.1. Digital TCP/IP Services for OpenVMS Alpha Version V4.1. Samba
2.0.6 and Frontport from Compaq website).

If I use TextPad to edit an existing file on a drive mapped from the Alpha
using Samba, the file is mangled on saving. Interestingly enough, files
edited using PFE don't seem to show the same behaviour.

Regards
Stephen

+++
EMail: stephen.hall at xlg.co.uk

> -----Original Message-----
> From: samba-vms-admin at lists.samba.org
> [mailto:samba-vms-admin at lists.samba.org]On Behalf Of Fachetti, Robert
> Sent: 05 December 2001 22:05
> To: 'John E. Malmberg'; samba-vms at samba.org
> Subject: Samba 2.0.6 on Alpha VMS - file writing problem
>
>
> John,
>
> To answer some of your questions:
>
> > Also what created the file originally?  That may make a big difference.
>
> The files are originally created by our own proprietary code generation
> tool. They may or may not have been modified by an OpenVMS Editor.
>
> > Is the behavior different if the file is in the root directory
> of a share
> than it is when in a subdirectory?
>
> The behavior is thus: When I copy a file (either doing a drag and
> drop, or a
> File->Save from an IDE or Notepad) back to VMS (into either the
> root of the
> share or a subdirectory) the following always occurs: If the file already
> exists in the destination directory, then the resulting file that gets
> copied back is corrupted. If the file does NOT exist in the destination
> directory, then the file gets copied correctly. It behaves the
> same whether
> my target is the root directory or a subdirectory.
>
> Before accessing from the PC side, I have tried to manipulate the file
> attributes to match those of the file that is coming back to the VMS side
> from the PC. I have tried using the following command on the files before
> access them from the PC:
>
> $ convert/fdl=STREAM.FDL FileName.ada FileName.ada
>
> where the contents of STREAM.FDL are as follows:
>
> $ type STREAM.FDL
> FILE
>         ALLOCATION              33
>         BEST_TRY_CONTIGUOUS     yes
>         EXTENSION               0
>         ORGANIZATION            sequential
> RECORD
>         BLOCK_SPAN              yes
>         CARRIAGE_CONTROL        carriage_return
>         FORMAT                  stream
>         SIZE                    0
> $
>
> But this does not seem to mitigate the problem. Maybe there are some other
> attributes I should be setting in the STREAM.FDL file?
>
> Thanks,
> Bob Fachetti
> fachetti at pweh.com
>
> -----Original Message-----
> From: John E. Malmberg [mailto:wb8tyw at qsl.net]
> Sent: Friday, November 30, 2001 12:05 AM
> To: samba-vms at samba.org
> Subject: RE: Running Samba 2.0.6 on Alpha VMS
>
>
> "Fachetti, Robert" <fachetti at pweh.company> wrote:
>  >
>  > VMS Users,
>  > Doing a "File->Save" results in: 1. The original file gets
>  > overwritten (it does not create a new version of the file e.g.
>  > NAME.TYPE;2) 2. The contents of the file are corrupted:
>
> Sometimes NOTEPAD saves a file over the old one, and sometimes it
> creates a temp file, deletes the old, and then renames it.  I have not
> figured out that rule.
>
> I thought I had that problem fixed.  But apparently not.  Is the
> behavior different if the file is in the root directory of a share than
> it is when in a subdirectory?
>
> Also what created the file originally?  That may make a big difference.
>
> The <CR> is from the PC program saving the file as <CR> delimited file,
> and UNIX knows that it should be saved as a <LF> delimited file, so the
> resulting file attributes are wrong.
>
> This is also the way it works on UNIX as people on the UNIX SAMBA forums
> have complained about it.
>
> If you look in the some of the documentation notes that came with the
> SAMBA 2.0.6 for OpenVMS kit, you can force SAMBA 2.0.6 for OpenVMS to
> set the file header to match the type for the extension when it creates
> a file that does not have a previous version.
>
> If it has a previous version, the existing attributes are inherited by
> the new file.  This could be what is causing the corruption you are
> seeing if the file was originally created by an OpenVMS editor.  But
> that still is a bug.
>
> I posted just a little while back, the file attributes that would
> probably get rid of the <CR>, but can not remember them off the top of
> my head.  It is either STREAM-CR or STREAM-LF.  It is late here right
> now, so I do not have time to look them up.
>
> -John
> wb8tyw at qsl.network
> Personal Opinion Only
>