GitLab

Detail:
  LanManFS does not like it if you create (independently, using a PC or
    otherwise) files with names like "myfile,fff" which you intend to
    be displayed as files with type &FFF (ie. Text) on a RISC OS machine.
    If you tried to access the file for reading it, such as loading it
    into an editor, that worked due to the name matching resolution.
    However, any attempt to update the file caused LanManFS to attempt
    to write the file without the extension and not notice that a file
    with a ,fff extension already existed (Text files are special cased
    in the current implementation of name translation - see LanManFS
    Functional Specification for details and rationale).  Attempts to
    save typically succeed (giving you two files: myfile and myfile,fff)
    but generate "Operation not permitted" or such like.  This stemmed
    from the attempt being made by LanManFS to rename a fil...

  Fixed search handle haemorrhaging.
Detail:
  The directory lookup routines cached directory search handles to avoid
    hammering the server with repeated requests to open directories.
    Unfortunately, it was possible for these to be forgotten without
    being freed up leading to resource loss at the server end.  Eventually,
    the server gives up servicing you and reports errors.  This will only
    occur once a significant number of accesses have been performed (the
    number depends entirely on server configuration).  This leak is now
    fixed.
Admin:
  Tested against Cerium - debug reports that no handles are being leaked.

Version 2.07. Tagged as 'LanManFS-2_07'

  Introduced new error message for re-entrancy prevention trap to use.
Detail:
  When 'pinging' an SMB server, LanManFS does not wait for any response
    but the response reading routine knows to just throw away any old
    SMBchkpth responses that it gets and try reading again.
  Re-entrancy trap now has its own error "LanManFS in use" &1663E, which
    means you no longer see "!Armboot files nested too deeply" which is
    confusing.  The only way you can provoke this message is if you use
    Alt-Break whilst the NetBIOS/IP code is executing.  The error plays
    the same part as "FileCore in use" does for FileCore.
Admin:
  Verified module still works and the anti idle-out features still work.

Version 2.04. Tagged as 'LanManFS-2_04'

Detail:
  Long filename flag tarnsferred to be a server property rather than
    a share property, otherwise subsequent shares to the same server
    do not get long filenames (because the subsequent shares don't
    have to go through the connection negotiation phase)
Admin:
  Tested on by mounting lots of drives through desktop Omni frontend.

Version 2.02. Tagged as 'LanManFS-2_02'

  Support for spaces in machine names.
  Merge of sbrodie_LanManFS_dev branch to trunk.
Detail:
  LanManFS 2.00 supports the "NT LM 0.12" protocol, enabling it to
    use long filenames on mounted shares.
Admin:
  Supporting documentation:
    1215,256/FS: LanManFS Software Functional Specification.
  Same as LanManFS-1_87_1_1_1_1_2_13.

Version 2.00. Tagged as 'LanManFS-2_00'

RiscOS/Sources/Networking/LanManFS is now locked out.

The rest of Omni will be imported at a later date.

Version 1.87, tagged as LanManFS-1_87