Rsnyc creates a temp. file which contains illegal windows characters

    • OMV 4.x
    • Rsnyc creates a temp. file which contains illegal windows characters

      It seems, that whenever a RSYNC is issued, that a temporary file is created, which contains illegal windows characters in the filename.

      This results in a windows application monitoring a certain folder on an OMV NAS to crash.
      Illegal windows filename characters are:
      • < (less than)
      • > (greater than)
      • : (colon)
      • " (double quote)
      • / (forward slash)
      • \ (backslash)
      • | (vertical bar or pipe)
      • ? (question mark)
      • * (asterisk)
      • Integer value zero, sometimes referred to as the ASCII NUL character.
      • Characters whose integer representations are in the range from 1 through 31.
      I know, that OMV is a Unix based system and as such doesn't care about windows file naming conventions, however, for better compatibility with windows users accessing this NAS, I guess, that this should be changed.

      Many Greets,
    • The temp file is the file name plus an extension created by mktemp util. Doesn’t have those chars, is just 5 alpha numeric chars.

      Rsync is a separate binary, Omv doesn’t mantain it in case those filenames are created the way you mention.

      How is that you are monitoring the folder? Is a smb share mounted as drive in windows ?
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10 broadcast channel
      openmediavault discord server
    • The monitoring is actually done by a C# application using the .Net FileSystemWatcher class (see here…temwatcher(v=vs.110).aspx).
      The exception being thrown is the following:

      Source Code

      1. Error Message: Illegal characters in path.
      2. Error Type: System.ArgumentException
      3. Error Source: mscorlib.Void CheckInvalidPathChars(System.String, Boolean)
      4. ********** System Stack Trace **********
      5. at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
      6. at System.IO.Path.GetFileName(String path)
      7. at System.IO.FileSystemWatcher.MatchPattern(String relativePath)
      8. at System.IO.FileSystemWatcher.NotifyFileSystemEventArgs(Int32 action, String name)
      9. at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* overlappedPointer)
      10. at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

      So yes, the smb share is mounded as a drive in windows,. The FileSystemWatcher monitors any file modification, deletion or creation within a certain folder of that drive and all its sub-folders.
      This exception is raised each time RSYNC is invoked. I don't know exactly what RSYNC is doing. But without issuing the RSYNC anymore, we got no exceptions anymore.
      So the only vital explanation to me is, that RSYNC must somewhere/showhow create a temp. file in the folder with an illegal windows chracter contained in it.
    • Run the rsync job manually verbosely on commands line to actually see what happens and maybe see if there is a path with a strange char. You can find the full Omv command in /var/lib/openmediavault/ prefixed with rsync-uuid

      Is this your software ? Can you make the class print the path when the exception happens ?

      I’ve use rsync and temp files are not generated with illegal chars, you can test rsync with a big file local transfer.

      If there where any illegal chars in the path samba is in charge to deal with it, and not show them in the shared folder.
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10 broadcast channel
      openmediavault discord server
    • Yes, it is my software, and I already tried to get/determine the illegal filename causing the issue, however, the exception is thrown before I can actually catch or print anything.
      The reason is, that the .Net FileSystemWatcher internally creates its own thread to monitor the defined folder and this thread crashes the app with the above exception directly from within the FileSystemWatcher - as such, I cannot print anything and as such I was so far unable to determine the root causing filename.
      I only know, that when I stop using Rsync, that all is working fine.