acrolinx

Author: b-ahibbard

articles/azure-netapp-files/understand-path-lengths.md

@@ -24,7 +24,7 @@ The following table shows the supported component and path lengths in Azure NetA
 >[!NOTE]
 >Dual-protocol volumes use the lowest maximum value. 
 
-If an SMB share name is `\\SMB-SHARE`, that adds 11 Unicode characters to the path length because each character is 1 byte. If the path to a specific file is `\\SMB-SHARE\apps\archive\file`, that is 29 Unicode characters; each character, including the slashes, is 1 byte. For NFS mounts, the same concepts apply. The mount path  `/AzureNetAppFiles` is 17 Unicode characters of 1 byte each. 
+If an SMB share name is `\\SMB-SHARE`, the share name adds 11 Unicode characters to the path length because each character is 1 byte. If the path to a specific file is `\\SMB-SHARE\apps\archive\file`, it's 29 Unicode characters; each character, including the slashes, is 1 byte. For NFS mounts, the same concepts apply. The mount path  `/AzureNetAppFiles` is 17 Unicode characters of 1 byte each. 
 
 Azure NetApp Files supports the same path length for SMB shares that modern Windows servers support: [up to 32,767 bytes](/windows/win32/fileio/maximum-file-path-limitation). However, depending on the version of the Windows client, some applications might not be able to [support paths longer than 260 bytes](/windows/win32/fileio/naming-a-file). Individual path components (the values between slashes, such as file or folder names) support up to 255 bytes. For instance, a file name using the Latin capital “A” (which takes up 1 byte per character) in a file path in Azure NetApp Files can't exceed 255 characters. 
 
@@ -41,9 +41,9 @@ mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 
 ## Discerning character sizes 
 
-The Linux utility [`uniutils`](https://billposer.org/Software/unidesc.html) can be used to find the byte size of Unicode characters by typing multiple instances of the character instance and viewing the “bytes” field.  
+The Linux utility [`uniutils`](https://billposer.org/Software/unidesc.html) can be used to find the byte size of Unicode characters by typing multiple instances of the character instance and viewing the **bytes** field.  
 
-**Example 1:** The Latin capital A increments by 1 byte each time it is used (using a single hex value of 41, which is in the 0-255 range of ASCII characters).
+**Example 1:** The Latin capital A increments by 1 byte each time it's used (using a single hex value of 41, which is in the 0-255 range of ASCII characters).
 
 ```
 # printf %b 'AAA' | uniname
@@ -56,7 +56,7 @@ character  byte  UTF-32   encoded as glyph      name
 
 **Result 1:** The name AAA uses 3 bytes out of 255.
 
-**Example 2:** The Japanese character 字 increments 3 bytes each instance. This can be also calculated by the 3 separate hex code values (E5 AD 97) under “encoded as.” Each hex value represents 1 byte:
+**Example 2:** The Japanese character 字 increments 3 bytes each instance. This can be also calculated by the 3 separate hex code values (E5, AD, 97) under the **encoded as** field. Each hex value represents 1 byte:
 
 ```
 # printf %b '字字字' | uniname
@@ -68,7 +68,7 @@ character  byte  UTF-32   encoded as  glyph     name
 
 **Result 2:** A file named 字字字 uses 9 bytes out of 255.
 
-**Example 3:** The letter Ä with diaeresis uses two bytes per instance (C3 + 84).
+**Example 3:** The letter Ä with diaeresis uses 2 bytes per instance (C3 + 84).
 
 ```
 # printf %b 'ÄÄÄ' | uniname
@@ -80,7 +80,7 @@ character  byte  UTF-32   encoded as     glyph  name
 
 **Result 3:** A file named ÄÄÄ uses 6 bytes out of 255.
 
-**Example 4:** A special character, such as the 😃 emoji, falls into an “undefined” range that exceeds the 0-3 bytes generally used for Unicode characters. As a result, it uses a surrogate pair for its character encoding. In this case, each instance of the character uses 4 bytes.
+**Example 4:** A special character, such as the 😃 emoji, falls into an undefined range that exceeds the 0-3 bytes used for Unicode characters. As a result, it uses a surrogate pair for its character encoding. In this case, each instance of the character uses 4 bytes.
 
 ```
 # printf %b '😃😃😃' | uniname
@@ -92,13 +92,13 @@ character  byte       UTF-32 encoded as  glyph   name
 
 **Result 4:** A file named 😃😃😃 uses 12 bytes out of 255.
 
-Most emojis fall into the 4 byte range, while others can extend out to up to 7 bytes. Of the more than one thousand standard emojis, approximately 180 are in the [Basic Multilingual Plane (BMP)](https://en.wikipedia.org/wiki/Plane_%28Unicode%29#Basic_Multilingual_Plane), which means they can be displayed as text or emoji in Azure NetApp Files, depending on the client’s support for the language type.
+Most emojis fall into the 4-byte range, while others can extend out to up to 7 bytes. Of the more than one thousand standard emojis, approximately 180 are in the [Basic Multilingual Plane (BMP)](https://en.wikipedia.org/wiki/Plane_%28Unicode%29#Basic_Multilingual_Plane), which means they can be displayed as text or emoji in Azure NetApp Files, depending on the client’s support for the language type.
 
 For more detailed information on the BMP and other Unicode planes, see [Understand volume languages in Azure NetApp Files](understand-volume-languages.md).
 
 ## Character byte impact on path lengths
 
-Although a path length is generally thought to be the number of characters in a file or folder name, it's is actually the _size_ of the supported bytes in the path. Since each character adds a byte size to a name, different character sets in different languages support different file name lengths.
+Although a path length is thought to be the number of characters in a file or folder name, it's actually the _size_ of the supported bytes in the path. Since each character adds a byte size to a name, different character sets in different languages support different file name lengths.
 
 Consider the following scenarios:
 
@@ -116,7 +116,7 @@ A grinning face emoji (😃) uses 4 bytes, which means that a file name with onl
 
 - A file or folder uses a combination of different characters (ie, Name字😃). 
 
-When different characters with different byte sizes are used in a file or folder name, then each character’s byte size factors in to the file or folder length. A file or folder name of Name字😃 would use 1+1+1+1+3+4 bytes (11 bytes) of that total 255 byte length.
+When different characters with different byte sizes are used in a file or folder name, each character’s byte size factors in to the file or folder length. A file or folder name of Name字😃 would use 1+1+1+1+3+4 bytes (11 bytes) of the total 255-byte length.
 
 #### Special emoji concepts
 
@@ -168,15 +168,15 @@ Using `\\?\Z:` instead allows access and supports longer file paths.
 
 ### Workaround if the max path length cannot be increased
 
-If the max path length cannot be enabled in the Windows environment, or the Windows client versions are too low to allow it to be enabled, there is a workaround. You can mount the SMB share deeper into the directory structure can reduce the queried path length.
+If the max path length can't be enabled in the Windows environment or the Windows client versions are too low, there's a workaround. You can mount the SMB share deeper into the directory structure can reduce the queried path length.
 
 For example, rather than mapping `\\NAS-SHARE\AzureNetAppFiles` to `Z:`, map `\\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4` to `Z:`.
 
 ## NFS path limits
 
-NFS path limits with Azure NetApp Files volumes have the same 255 byte limit for individual path components. Each component, however, is evaluated one at a time and can process up to 4,096 bytes per request with a near limitless total path length. For instance, if each path component is 255 bytes, an NFS client can evaluate up to 15 components per request (including `/` characters). As such, a `cd` request to a path over the 4,096-byte limit yields a "File name too long" error message. 
+NFS path limits with Azure NetApp Files volumes have the same 255-byte limit for individual path components. Each component, however, is evaluated one at a time and can process up to 4,096 bytes per request with a near limitless total path length. For instance, if each path component is 255 bytes, an NFS client can evaluate up to 15 components per request (including `/` characters). As such, a `cd` request to a path over the 4,096-byte limit yields a "File name too long" error message. 
 
-In most cases, Unicode characters are 1 byte or less, so the 4,096-byte limit generally corresponds to 4,096 characters. If a character is larger than 1 byte in size, then the path length is less than 4,096 characters. Characters with a size greater than 1 byte in size count more against the total character count than 1 byte characters.
+In most cases, Unicode characters are 1 byte or less, so the 4,096-byte limit corresponds to 4,096 characters. If a character is larger than 1 byte in size, then the path length is less than 4,096 characters. Characters with a size greater than 1 byte in size count more against the total character count than 1-byte characters.
 
 The path length max can be queried using the `getconf PATH_MAX /NFSmountpoint` command.
 
@@ -185,7 +185,7 @@ The path length max can be queried using the `getconf PATH_MAX /NFSmountpoint` c
 
 ## Dual-protocol volume considerations 
 
-When using Azure NetApp Files for dual protocol access (SMB and NFS on the same datasets), the difference in how path lengths are handled in those protocols can create incompatibilities across file and folders. For instance, Windows SMB supports up to 32,767 characters in a path (provided the long path feature is enabled on the SMB client), but NFS support can exceed that amount. As such, if a path length is created in NFS that exceeds the support of SMB, clients will not be able to access the data once the path length maximums have been reached. In those cases, either take care to consider the lower end limits of file path lengths across protocols when creating file and folder names (and folder path depth) or map SMB shares closer to the desired folder path to reduce the path length.
+When using Azure NetApp Files for dual protocol access (SMB and NFS on the same datasets), the difference in how path lengths are handled in those protocols can create incompatibilities across file and folders. For instance, Windows SMB supports up to 32,767 characters in a path (provided the long path feature is enabled on the SMB client), but NFS support can exceed that amount. As such, if a path length is created in NFS that exceeds the support of SMB, clients are unable to access the data once the path length maximums have been reached. In those cases, either take care to consider the lower end limits of file path lengths across protocols when creating file and folder names (and folder path depth) or map SMB shares closer to the desired folder path to reduce the path length.
 
 Instead of mapping the SMB share to the top level of the volume to navigate down to a path of `\\share\folder1\folder2\folder3\folder4`, consider mapping the SMB share to the entire path of `\\share\folder1\folder2\folder3\folder4`. As a result, a drive letter mapping to `Z:` lands in the desired folder and reduces the path length from `Z:\folder1\folder2\folder3\folder4\file` to `Z:\file`.
 
@@ -197,7 +197,7 @@ If you use a character that Azure NetApp Files doesn't support, you might see a
 
 :::image type="content" source="./media/understand-path-lengths/dialog-cannot-find.png" alt-text="Screenshot of an invalid file name warning.":::
 
-Rather than the name being too long, the error actually results from the character byte size being too large for the for the Azure NetApp Files volume to use over SMB. There is no workaround in Azure NetApp Files for this limitation. For more information on special character handling in Azure NetApp Files, see [Protocol behavior with special character sets](understand-volume-languages.md#protocol-behaviors-with-special-character-sets).
+Rather than the name being too long, the error actually results from the character byte size being too large for the Azure NetApp Files volume to use over SMB. There's no workaround in Azure NetApp Files for this limitation. For more information on special character handling in Azure NetApp Files, see [Protocol behavior with special character sets](understand-volume-languages.md#protocol-behaviors-with-special-character-sets).
 
 ## Next steps