I recieved the following error code: EINVAL: Invalid argument [open]
I am transferring (Mirror) from Linux OS Drive to 2TB exFAT external portable drive.
I believe the error is due to the conclusion reached in this forum thread:
viewtopic.php?t=8159&hilit=Invalid+argument+%5Bopen%5D#p36783
...special characters allowed in Linux file systems but not exFAT. (asterisk, question mark, colon, etc...)
...also any trailing extra period (.) or spaces at the end of the file name can lead to similar problems
I am not personally choosing to save the files with the special characters (created by other programs and processes) even though they are allowed in Linux - but I don't want to have to manually change the file names every time as FFS will not perform backup of them.
(Windows does not typically have such a problem because the special characters are not allowed)
Given the inherent naming convention differences and incompatabilities...
--> Does anyone have a best practice recommendation for transferring from Linux to 2TB exFAT?
(or an efficient systematic workaround)
Thank you
Best Practice Recommendation - FFS / Linux / exFAT external drive - EINVAL: Invalid argument [open]
- Posts: 1
- Joined: 4 Sep 2023
- Posts: 1037
- Joined: 8 May 2006
(If FFS "translated" a character, physically, on the target end, there is still the issue that the source name is not changed, so the next Compare will still find the same file.
If FFS had an option to "treat as equal", so ".$" (ending dot) is truncated (to "$"), then it could compare source with ".$" against same name without the ending (.), transparently. But then, source end could have both "name" (no dot) & "name." (with dot), & what to do then? So if source "name." is treated equal to target "name", then how does source "name" & target "name" then play out? The same could occur even if you substituted a (an everywhere) "legal" character. So if ".$" is translated to "_$" (ending _ char), you're left in the same boat, as you could have sources of "name_" & "name." & on target, "name_" (stays the same, &) is "name_", & "name." then also wants to be "name_" which wouldn't work.
Conundrum ;-).
I'm thinking... the manual method. Every so often, on the source (Linux) end, search for file names with "illegal" characters, & replace (or remove) them on the source (& assuming there are no collisions in that respect), then they should "just copy over" to the target.)
Search: regex:\.$ | regex:\s$
Results (ending '.', & trailing space - on Windows, as it is):
If FFS had an option to "treat as equal", so ".$" (ending dot) is truncated (to "$"), then it could compare source with ".$" against same name without the ending (.), transparently. But then, source end could have both "name" (no dot) & "name." (with dot), & what to do then? So if source "name." is treated equal to target "name", then how does source "name" & target "name" then play out? The same could occur even if you substituted a (an everywhere) "legal" character. So if ".$" is translated to "_$" (ending _ char), you're left in the same boat, as you could have sources of "name_" & "name." & on target, "name_" (stays the same, &) is "name_", & "name." then also wants to be "name_" which wouldn't work.
Conundrum ;-).
I'm thinking... the manual method. Every so often, on the source (Linux) end, search for file names with "illegal" characters, & replace (or remove) them on the source (& assuming there are no collisions in that respect), then they should "just copy over" to the target.)
Search: regex:\.$ | regex:\s$
Results (ending '.', & trailing space - on Windows, as it is):
test.
test.file.with.trailing.space
