When mirroring (both two-way and one-way) on a folder containing only two files ("PRN.csv" and "PRN.txt"), the "PRN" filename is changed to "PITWVK_3" on both files in the second folder.
To investigate this issue, I then manually copied both "PRN" the files to the second folder and deleted the two "PITWVK~3" files. Windows (11 Pro, version 23H2) and DOS have no issues with copying the files correctly.
I then ran Compare on the two folders which both now contain the correct "PRN" files.
Simply running Compare (and not yet running Synchronize) changed both filenames in the second folder from "PRN" to "PITWVK~3"!
Compare should not be changing any filenames!
I have attached the files for your convenience in testing this.
I am running FFS 13.7 (Donation Edition).
Error copying "PRN.csv" and "PRN.txt" files. Copied filenames are changed.
-
- Posts: 4056
- Joined: 11 Jun 2019
https://forums.debian.net/viewtopic.php?t=144738
This describes the exact same issue with the same file name, and leads to this:
https://askubuntu.com/questions/835356/mv-error-in-shell-script-are-the-same-file
These are on Linux, but that all seem to revolve around an issue with and SMB share being mounted weird
This describes the exact same issue with the same file name, and leads to this:
https://askubuntu.com/questions/835356/mv-error-in-shell-script-are-the-same-file
These are on Linux, but that all seem to revolve around an issue with and SMB share being mounted weird
- Posts: 6
- Joined: 22 Oct 2024
Thank you for your quick response :)
You are correct that the second folder is accessed via SMB, but the main issue here is that simply running FFS Compare should not change any filenames.
Investigating further, I created empty text files with the names "CON", "AUX", and "NUL" and manually copied them to the second folder, and they were fine, so the issue does not appear to be SMB itself.
Running FFS Compare changed ALL of these filenames in the second folder.
It appears that perhaps all Windows "reserved filenames" would be affected. This would include:
PRN, CON, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
Again, however, simply running FFS Compare should not change any filenames. Please investigate the code in FFS Compare to determine why it is causing the filenames on the SMB server to be changed.
You are correct that the second folder is accessed via SMB, but the main issue here is that simply running FFS Compare should not change any filenames.
Investigating further, I created empty text files with the names "CON", "AUX", and "NUL" and manually copied them to the second folder, and they were fine, so the issue does not appear to be SMB itself.
Running FFS Compare changed ALL of these filenames in the second folder.
It appears that perhaps all Windows "reserved filenames" would be affected. This would include:
PRN, CON, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
Again, however, simply running FFS Compare should not change any filenames. Please investigate the code in FFS Compare to determine why it is causing the filenames on the SMB server to be changed.
- Posts: 6
- Joined: 22 Oct 2024
Another investigation, I just used WinSCP to copy the files from the first folder to the second folder. It also changed the filenames.
I again used windows drag and drop, and the filenames looked good, but when I refreshed the second folder, the filenames were changed.
It now appears that this issue IS NOT with FFS Compare, but is with either SMB or Windows iteslf. I will investigate further into SMB and see what is happening and update this posting with my findings.
Meanwhile, I can work around this by prepending a letter (like 'z') to the filenames in my first folder.
Thank you for your assistance and guidance.
I again used windows drag and drop, and the filenames looked good, but when I refreshed the second folder, the filenames were changed.
It now appears that this issue IS NOT with FFS Compare, but is with either SMB or Windows iteslf. I will investigate further into SMB and see what is happening and update this posting with my findings.
Meanwhile, I can work around this by prepending a letter (like 'z') to the filenames in my first folder.
Thank you for your assistance and guidance.
- Posts: 6
- Joined: 22 Oct 2024
I've isolated the problem to SMB. Copying the files manually to a second Windows folder does NOT change the filenames, but copying them to the SMB folder (with DOS 'copy', Windows 'drag and drop', and Windows 'copy' and 'paste') does.
I will continue to investigate SMB.
I will continue to investigate SMB.
- Posts: 6
- Joined: 22 Oct 2024
THIS ISSUE IS NOW RESOLVED.
I found that SAMBA defaults to "mangled names = yes". A setting (mangled names = no) can be added to remove this behavior, which was necessary for DOS, but is no longer needed for current versions of Windows.
For OMV (Open Media Vault), I added the setting (mangled names = no) in the browser GUI under Services | SMB/CIFS | Settings, in the Extra Options box beneath Advanced Settings.
For ReadyNAS, I had to ssh into the server and use vi to add the setting (mangled names = no) to the appropriate configuration file (in my case it was /etc/samba/smb.conf).
Keep up the great work with FFS! I hope this posting can help other users with similar issues.
NOTE: I do NOT advocate turning mangled names off in general, especially for users that may have DOS or early Windows machines still in operation that need to access files on the SAMBA drive. For a more comlete reference, please see the SAMBA documentation at https://www.samba.org/samba/docs/4.9/man-html/smb.conf.5.html.
I found that SAMBA defaults to "mangled names = yes". A setting (mangled names = no) can be added to remove this behavior, which was necessary for DOS, but is no longer needed for current versions of Windows.
For OMV (Open Media Vault), I added the setting (mangled names = no) in the browser GUI under Services | SMB/CIFS | Settings, in the Extra Options box beneath Advanced Settings.
For ReadyNAS, I had to ssh into the server and use vi to add the setting (mangled names = no) to the appropriate configuration file (in my case it was /etc/samba/smb.conf).
Keep up the great work with FFS! I hope this posting can help other users with similar issues.
NOTE: I do NOT advocate turning mangled names off in general, especially for users that may have DOS or early Windows machines still in operation that need to access files on the SAMBA drive. For a more comlete reference, please see the SAMBA documentation at https://www.samba.org/samba/docs/4.9/man-html/smb.conf.5.html.
- Posts: 1038
- Joined: 8 May 2006
Let me see if I'm understanding this correctly...
So the issue was not "reserved filenames".
As PRN <> PRN.txt nor PRN.csv.
But "Mangling".
And PRN.txt & PRN.csv were mangled - why, because the extensions were in lower case?
So if before changing your mangling setting, your files had been named,
PRN.TXT & PRN.CSV, then mangling would not have kicked in, & the names would have been left as is?
So the issue was not "reserved filenames".
As PRN <> PRN.txt nor PRN.csv.
But "Mangling".
And PRN.txt & PRN.csv were mangled - why, because the extensions were in lower case?
So if before changing your mangling setting, your files had been named,
PRN.TXT & PRN.CSV, then mangling would not have kicked in, & the names would have been left as is?
- Posts: 6
- Joined: 22 Oct 2024
It has nothing to do with upper or lower case of either the filename or the extension.
In DOS, if you try to print to a file named prn.txt, prn.csv, or prn.xxx, your data gets sent to PRN (which is the printer) instead of to a file. If you try to print to a file named con.txt, con.csv, or con.xxx, your data gets sent to CON (which is the console [the monitor]) instead of to a file.
Old versions of Windows honored this. In fact, Windows 1.0 - 3.11 were just GUI facades on top of DOS (see https://en.wikipedia.org/wiki/Microsoft_Windows_version_history#:~:text=The%20first%20versions%20of%20Windows,code%20ported%20from%20Windows%203.1.).
In order to maintain compatability with DOS and early versions of Windows, SAMBA defaults to mangling the filename for files that use DOS "reserved filenames". Turning this off resolves the issue.
Note, though, that mangling also checks for other filename characters that are not valid in Windows such as a colon, asterisk, question mark, etc. (see https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file). That is why I dont advocate turning off mangled names as general advice for everyone. As I mentioned earlier, a suitable workaround would be to name files in such a way as to avoid using "reserved filenames" or "reserved characters".
In DOS, if you try to print to a file named prn.txt, prn.csv, or prn.xxx, your data gets sent to PRN (which is the printer) instead of to a file. If you try to print to a file named con.txt, con.csv, or con.xxx, your data gets sent to CON (which is the console [the monitor]) instead of to a file.
Old versions of Windows honored this. In fact, Windows 1.0 - 3.11 were just GUI facades on top of DOS (see https://en.wikipedia.org/wiki/Microsoft_Windows_version_history#:~:text=The%20first%20versions%20of%20Windows,code%20ported%20from%20Windows%203.1.).
In order to maintain compatability with DOS and early versions of Windows, SAMBA defaults to mangling the filename for files that use DOS "reserved filenames". Turning this off resolves the issue.
Note, though, that mangling also checks for other filename characters that are not valid in Windows such as a colon, asterisk, question mark, etc. (see https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file). That is why I dont advocate turning off mangled names as general advice for everyone. As I mentioned earlier, a suitable workaround would be to name files in such a way as to avoid using "reserved filenames" or "reserved characters".
-
- Posts: 4056
- Joined: 11 Jun 2019
Good freaking work figuring that out! I will definitely tuck this away into a deep crevice of my brain lol
- Posts: 1038
- Joined: 8 May 2006
DIR > CON.ididntknowthatIf you try to print to a file named con.txt, con.csv, or con.xxx, your data gets sent to CON (which is the console [the monitor]) instead of to a file.
Neat.
Thanks :-).
