[comp.sys.next] WARNING: Potentially Dangerous Problem with Edit

powell@hqda-ai.UUCP (Robert Powell) (10/18/90)

Greetings,

After reading a recent post concerning a problem with Edit, I thought I should
let you all know about another potentially devastating problem.  This problem
results from an unfortunate synergy between Edit and HP/UX's filename length
limit.

A couple of months ago I was using Edit on some files which were sitting on an
HP9000/835 which was NFS mounted on my NeXT.  I had a Shell open that was
rlogged into the HP so that I could do a make and test the program.  In Edit's
Preferences I had set the "Delete backup file" switch in the "Save Options"
box, since I don't like having all those filename~ files hanging around.  After editing a certain source code file, let's call it long.file.name, I saved it
and then did a make.  It claimed that it couldn't find long.file.name.  I
checked, and sure enough, it was gone.  I went back to Edit and saw that the
new long.file.name was still loaded, and the X in the close button indicated
that it had saved.  After some investigation, here's what I found: The HP had
its built in filename length limit set to 14 chars.  Any filename longer than
that gets truncated.  When I hit save, the following three things happened:

  1. Edit copied or moved long.file.name to long.file.name~, making the backup.
     But since long.file.name~ was longer than 14 characters, it got truncated
     to long.file.name, so they were identical.  So nothing probably happened.
  2. Edit wrote out long.file.name, overwriting the old one, which was okay.
  3. Edit then tried to delete the backup, so it removed long.file.name~, which
     got truncated to long.file.name, so the new file that I just saved got
     deleted.

So now neither the old version nor the new verion of long.file.name exist,
except in Edit's buffer.  A person could lose a lot of code before figuring out
what's going on.  Three possible solutions come to mind:

  1.  Use shorter filenames.
  2.  Set Edit's Preferences to "Don't delete backup file".
  3.  Increase HP/UX's filename length limit.

I chose solution #1 since that still lets me avoid having backup files hanging
around.  Also, I seem to remember trying solution #2, and still having
problems.  It seems that steps 1 and 2 of Edit's save procedure may happen in
reverse order from what I have.  This would cause you to always end up with
old versions of your files, since the backup file would overwrite the new file.
Solution #3 could work, I wasn't able to persuade the sysadmin of the HP to
make the changes for me.  Also, even if it is increased to some finite length,
the problem of unknowingly exceeding it exists.
 
Please note that this is from memory, and I'm not in a position to test it out
now.  Also, this could be a problem with any editor/unix combination in which
the editor acts like Edit, and the unix has a filename length limit.

Good luck,

Bob Powell

/----------------< "Without chemicals he points" - The Giant >----------------\
| Robert H. Powell - Connectionist Incognito     US Army AI Center            |
| rhp@inel.gov   or                              Pentagon   Room 1D659        |
| powell@pentagon-gw.army.mil                    (ATTN: Bob Powell)           |
| (703) 614-6901                                 Washington, D.C.  20310-0200 |
\-----------------------------------------------------------------------------/

dorner@pequod.cso.uiuc.edu (Steve Dorner) (10/18/90)

In article <53474@hqda-ai.UUCP> powell@hqda-ai.UUCP (Robert Powell) writes:
>Three possible solutions come to mind:
>
>  1.  Use shorter filenames.
>  2.  Set Edit's Preferences to "Don't delete backup file".
>  3.  Increase HP/UX's filename length limit.

You forgot the obvious one:

   4.  Fix Edit to actually LOOK at result codes from file operations.


--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner