Skip to main content
added 1 character in body
Source Link
slm
  • 379.7k
  • 127
  • 793
  • 897

These messages look like the underlying software you're using to do the mounting cannot handle the special characters that wget is using due to the --restricrestrict-file-names=windows argument.

cp: cannot create directory `/mnt/Desktop/WebSites/foo/www.johndoeandjanedoe.com/ru/\321%81ка\321%87а\321%82\321%8C': Protocol error

Per the wget man page

--restrict-file-names=modes

Change which characters found in remote URLs must be escaped during generation of local filenames. Characters that are restricted by this option are escaped, i.e. replaced with %HH, where HH is the hexadecimal number that corresponds to the restricted character. This option may also be used to force all alphabetical cases to be either lower- or uppercase.

...

When "windows" is given, Wget escapes the characters , |, /, :, ?, ", *, <, >, and the control characters in the ranges 0--31 and 128--159. In addition to this, Wget in Windows mode uses + instead of : to separate host and port in local file names, and uses @ instead of ? to separate the query portion of the file name from the rest. Therefore, a URL that would be saved as www.xemacs.org:4300/search.pl?input=blah in Unix mode would be saved as www.xemacs.org+4300/search.pl@input=blah in Windows mode. This mode is the default on Windows.

To confirm this I'd try using 7z to create a compressed archive of the directory (recursively), copy that file over, and then uncompress it on Windows.

NOTE: The issue is likely with those special characters that wget is using when you specify that it should output files for consumption on Windows, in combination with the software being used to do the mounting.

These messages look like the underlying software you're using to do the mounting cannot handle the special characters that wget is using due to the --restric-file-names=windows argument.

cp: cannot create directory `/mnt/Desktop/WebSites/foo/www.johndoeandjanedoe.com/ru/\321%81ка\321%87а\321%82\321%8C': Protocol error

Per the wget man page

--restrict-file-names=modes

Change which characters found in remote URLs must be escaped during generation of local filenames. Characters that are restricted by this option are escaped, i.e. replaced with %HH, where HH is the hexadecimal number that corresponds to the restricted character. This option may also be used to force all alphabetical cases to be either lower- or uppercase.

...

When "windows" is given, Wget escapes the characters , |, /, :, ?, ", *, <, >, and the control characters in the ranges 0--31 and 128--159. In addition to this, Wget in Windows mode uses + instead of : to separate host and port in local file names, and uses @ instead of ? to separate the query portion of the file name from the rest. Therefore, a URL that would be saved as www.xemacs.org:4300/search.pl?input=blah in Unix mode would be saved as www.xemacs.org+4300/search.pl@input=blah in Windows mode. This mode is the default on Windows.

To confirm this I'd try using 7z to create a compressed archive of the directory (recursively), copy that file over, and then uncompress it on Windows.

NOTE: The issue is likely with those special characters that wget is using when you specify that it should output files for consumption on Windows, in combination with the software being used to do the mounting.

These messages look like the underlying software you're using to do the mounting cannot handle the special characters that wget is using due to the --restrict-file-names=windows argument.

cp: cannot create directory `/mnt/Desktop/WebSites/foo/www.johndoeandjanedoe.com/ru/\321%81ка\321%87а\321%82\321%8C': Protocol error

Per the wget man page

--restrict-file-names=modes

Change which characters found in remote URLs must be escaped during generation of local filenames. Characters that are restricted by this option are escaped, i.e. replaced with %HH, where HH is the hexadecimal number that corresponds to the restricted character. This option may also be used to force all alphabetical cases to be either lower- or uppercase.

...

When "windows" is given, Wget escapes the characters , |, /, :, ?, ", *, <, >, and the control characters in the ranges 0--31 and 128--159. In addition to this, Wget in Windows mode uses + instead of : to separate host and port in local file names, and uses @ instead of ? to separate the query portion of the file name from the rest. Therefore, a URL that would be saved as www.xemacs.org:4300/search.pl?input=blah in Unix mode would be saved as www.xemacs.org+4300/search.pl@input=blah in Windows mode. This mode is the default on Windows.

To confirm this I'd try using 7z to create a compressed archive of the directory (recursively), copy that file over, and then uncompress it on Windows.

NOTE: The issue is likely with those special characters that wget is using when you specify that it should output files for consumption on Windows, in combination with the software being used to do the mounting.

Source Link
slm
  • 379.7k
  • 127
  • 793
  • 897

These messages look like the underlying software you're using to do the mounting cannot handle the special characters that wget is using due to the --restric-file-names=windows argument.

cp: cannot create directory `/mnt/Desktop/WebSites/foo/www.johndoeandjanedoe.com/ru/\321%81ка\321%87а\321%82\321%8C': Protocol error

Per the wget man page

--restrict-file-names=modes

Change which characters found in remote URLs must be escaped during generation of local filenames. Characters that are restricted by this option are escaped, i.e. replaced with %HH, where HH is the hexadecimal number that corresponds to the restricted character. This option may also be used to force all alphabetical cases to be either lower- or uppercase.

...

When "windows" is given, Wget escapes the characters , |, /, :, ?, ", *, <, >, and the control characters in the ranges 0--31 and 128--159. In addition to this, Wget in Windows mode uses + instead of : to separate host and port in local file names, and uses @ instead of ? to separate the query portion of the file name from the rest. Therefore, a URL that would be saved as www.xemacs.org:4300/search.pl?input=blah in Unix mode would be saved as www.xemacs.org+4300/search.pl@input=blah in Windows mode. This mode is the default on Windows.

To confirm this I'd try using 7z to create a compressed archive of the directory (recursively), copy that file over, and then uncompress it on Windows.

NOTE: The issue is likely with those special characters that wget is using when you specify that it should output files for consumption on Windows, in combination with the software being used to do the mounting.