long filename issues

  • sjlevy

    (@sjlevy)


    9 years, 1 month ago

    I am using Comet Cache on a Windows/IIS instance of WordPress (I know, not recommended, but cant get around it)

    Comet Cache has been working fine other than an issue involving cache file paths exceeding the windows/ntfs limit of 260 characters.

    Some of my users frequently use long post names– those long names combined with the root path and the 22 char comet cache generated tmp extension will put these cache files over the limit and causes them to fail to write to disk.

    For example:
    Comet Cache: failed to write cache file for:
    D:\inetpub\wwwroot/wp-content/cache/comet-cache/cache/https/subdomain-mydomain-com/2016/03/31/this-is-a-really-long-post-title-that-is-likely-to-exceed-the-270-character-limit-on-a-windows-filesystem-abcdefghijklmnopqrstuvwxyz12345.html-58de7e3b5fc6b565648379-tmp

    Is there any way to configure Comet Cache to use filenames based on post ID instead of permalink/slug?

    So filenames would be shorter:
    D:\inetpub\wwwroot/wp-content/cache/comet-cache/cache/https/subdomain-mydomain-com/2904.html-58de7e3b5fc6b565648379-tmp

    Thank you

Viewing 6 replies - 1 through 6 (of 6 total)
  • Raam Dev

    (@raamdev)

    9 years, 1 month ago

    @sjlevy A few years ago we worked in a fix for overly long filenames (see this GitHub issue):

    Any http://host/path/[component]/ that is longer than 200 chars is converted to lpc-sha1([component]). Any overall http://host/[path] that is longer than 2000 chars, is converted to lp-sha1([path]).

    See this section of code where long paths and compoents are compacted.

    It sounds like you might need to tweak the maximum path length and/or the maximum component length, is that correct? If you could try playing around with those and see if that solves your issue and then report back, that would be great. If that does it for you, I’ll see about getting a filter in the next release that allows you to customize that without modifying core plugin files.

    Raam Dev

    (@raamdev)

    9 years, 1 month ago

    @sjlevy writes…

    the root path and the 22 char comet cache generated tmp extension will put these cache files over the limit and causes them to fail to write to disk.

    The error message you included in your response doesn’t say anything about a maximum filename length, rather it just says “failed to write cache file”. How are you determining that the failure was caused by a long filename and not by something else?

    I was reviewing the Wikipedia page on limits for NTFS:

    The pathname can be up to 32,767 unicode characters in length, with each path component (directory or filename) up to 255 characters.

    The example filename you provided above, even with the -tmp suffix, is only 169 characters long, well under the 255-maximum for NTFS.

    Thread Starter sjlevy

    (@sjlevy)

    9 years, 1 month ago

    Raam,

    Thank you for being so responsive

    I apologize for not replying sooner, yes I probably made the wrong assumption. There could be something else locking the file.

    I will continue to investigate.

    hunderson

    (@hunderson)

    9 years, 1 month ago

    I have used “Long Path Tool” in this situation and it helped me easily and quickly. This tool can fix all the error messages like:

    1. Path too long
    2. Cannot delete file: cannot read from source file or disk
    3. Cannot delete file: Access is denied
    4. There has been a sharing violation.
    5. The source or destination file may be in use.
    6. The file is in use by another program or user.
    7. The file name you specified is not valid or too long. Specify a different file name.

    and all other related error messages.
    I hope you will find this solution helpful and don’t forget to leave your comments.

    Thread Starter sjlevy

    (@sjlevy)

    9 years, 1 month ago

    After further inspection I still believe this to be a long filename issue

    The error was very repeatable with long post name entries

    I browsed to one of the paths, and attempted to write the same filename that comet-cache is.

    The filename was being truncated once the path hit 247 chars (windows path limitation is technically 260 but it wants allowance for 12 characters plus 1 null character, 247+12+1 = 260)

    From Microsoft: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath

    Maximum Path Length Limitation

    In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:\some 256-character path string<NUL>” where “<NUL>” represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

    By changing the character limit in the code cited by Raam I was able to resolve the issue. I altered lines 147 and 153 of Shared/CachePathUtils.php — down from 201 to a lower number.

    It appears that the length check in CachePathUtils is looking at the URL length instead of the filesystem path length, revising that code might resolve the issue for all Windows server users.

    • This reply was modified 9 years, 1 month ago by sjlevy.
    • This reply was modified 9 years, 1 month ago by bdbrown.
    Raam Dev

    (@raamdev)

    9 years, 1 month ago

    @sjlevy Thanks for the update. I’m noting the Comet Cache GitHub issue that you opened regarding this issue so that others can follow along: https://github.com/websharks/comet-cache/issues/888

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘long filename issues’ is closed to new replies.