home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.96 / text2725.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  1.8 KB  |  58 lines
  1.     id m0txnTn-0007qQa; Fri, 15 Mar 96 21:20 MST
  2. Sender: owner-executor
  3. Received: by ftp.ardi.com (Smail3.1.29.1 #3)
  4.     id m0txnHM-0007qVC; Fri, 15 Mar 96 21:07 MST
  5. Content-transfer-encoding: 7bit
  6. Received: from andromeda by rna.bio.mq.edu.au (Mercury 1.21);
  7. Priority: Normal
  8. Message-id: <A16BC67198@rna.bio.mq.edu.au>
  9. Mime-version: 1.0
  10. Subject: Re: E/L (and possibly others) 1.99q9 BUG: will not recognize
  11. Cc: "executor@ardi.com" <executor@ardi.com>
  12. X-mailer: PMMail 1.5 (Red Beta Build 108)
  13. Content-type: text/plain; charset="us-ascii"
  14. Reply-to: "Alexander Newman" <anewman@rna.bio.mq.edu.au>
  15. To: "Ian Viemeister" <vmeister@ios.com>
  16. From: "Alexander Newman" <anewman@rna.bio.mq.edu.au>
  17. Date: Sat, 16 Mar 96 15:09:48 +1000
  18. Sender: owner-executor@ardi.com
  19. Precedence: bulk
  20.  
  21. On Fri, 15 Mar 1996 18:20:15 -0500, Ian Viemeister wrote:
  22.  
  23. snip...
  24.  
  25. >I guess when saving to the unix filesystem, the filename is passed
  26. right 
  27. >thru, but when saving to an hfv, it uses the real HFS filesystem.
  28. >
  29. >>There's either one of three things wrong here:
  30. >>
  31. >>a) "FAQ- Running Executor under FreeBSD" is NOT a valid Mac filename,
  32. and
  33. >>   either Word and/or Executor was at fault in NOT telling me "hey,
  34. that's
  35. >>   not a good filename" when I saved it.
  36. >
  37. >That sounds like it
  38.  
  39. snip...
  40.  
  41. >Sounds like this would happen on Linux, FreeBSD or Win95 (does E/D
  42. under OS/2 
  43. >support LFNs?}
  44.  
  45. Unfortunately DOS under OS/2 is still restricted to 8.3, and the use of
  46. a file-system translator such as AMOS only appears to work from a
  47. natively-booted DOS (but that may have changed recently). The bottom
  48. line is therefore 'no'. As reported by others above, the 31-char Mac
  49. filename is the theoretical upper limit. (I believe Mac files can have
  50. a '0' or null filename - how the Mac filesystem copes with that I have
  51. no idea.)
  52.  
  53. Cheers,
  54.  
  55. Alex Newman
  56.  
  57.  
  58.