Jump to content
Comet Forums

Shorten long file names and add a special <task>.file_renamed.bc! file

Recommended Posts


I apologize in advance if this request, or something similar, has been submitted to the Forum; I could not find anything in the same vein.

I have several torrents that have been rejected by Bitcomet, version 1.89 Windows and earlier.  I suspect those torrents were rejected because they contain files that are deeply nested in sub-directories, resulting in one or more files with extremely long filenames that are not acceptable to Windows 10.  When I deselected those files with long names, Bitcomet accepts the torrent.  I suppose the files are "ok" on the uploader's computer (unknown OS).  But the uploader had created the torrent with a different "layout" that effectively extends the individual filenames.

My request is: (1) when Bitcomet detects an error due to long filenames, it should shorten the filenames.  (2) If any filenames have been shortened, Bitcomet should create a special file (suggest <task>.file_renamed.bc!) that records the mapping of the shortened name to the original name.

Many thanks in advance.

Link to comment
Share on other sites

The length of file names is a Windows problem really and, as you found out, it also involves sub and sub/sub folders.

There's nothing that BitComet can do about that - you'd be best bringing it up with MS as it's their algorithm that is the problem

Link to comment
Share on other sites

  • 2 weeks later...

@RhubarbPlease forward my request to the development team.  This is something that Bitcomet can do, with small & simple change to the code.  My suggestion is for Bitcomet to truncate the long filenames and create a text file that contains the mapping of the shortened names to the original names.

Link to comment
Share on other sites

I repeat:

Long path/file names are a Windows problem - it's NOTHING to  do with BitComet

You need to ask Microsoft to fix it as there is nothing the BC devs can do to fix an underlying problem in the OS

Link to comment
Share on other sites

I am suggesting a workaround.  Even Unix (and therefore MacOS) has pathname limits -- each component (the part between the / separator) of a path must be shorter than 255 bytes.  That is, each directory and the final filename component must be shorter than 255 bytes.  There is no limit on the full path (unlike Windows).  See the _PC_NAME_MAX and _PC_PATH_MAX entries in the fpathconf(3) man page.

I request the following workaround:

Bitcomet attempts to create a file with the original name.  If this attempt fails, it repeats the attempt with a shorter name.  Eventually, the attempt succeeds.  After that, the content is downloaded as per usual.  The hash checking does not depend on the filename, except when the user requests a hash-check; in which case, Bitcomet would need to consult the mapping file.

Bitcomet already has a non-conforming feature -- the special <task>.piece_part.bc! file.  My suggestion introduces a new special file which contains the filename mapping.

Link to comment
Share on other sites

I think I now know the Windows issue that you are referring to.  I am not talking about the 8.3 filename limit of ancient Windows.  The modern NTFS filesystem has lifted this limit -- files can have names that are longer than 8 bytes.  However, there is a still a limit on the full absolute pathname and I think that limit is 255 (not counting the drive letter and the null terminator).

I have checked my book Advanced Programming in the UNIX Environment (3ed) by Richard Stevens & Stephen Rago.  Figure 2.15 puts down the absolute pathname limit for MacOS 10.6.8 as 1024 bytes.  This is 4 times the limit in NTFS.  But still, it is a finite number.  Some uploaders may create their torrent with a long top-dir name such that the longest pathname exceeds this MacOS limit.  Such torrents will fail on Windows and MacOS.  Only Linux with an absolute pathname limit of 4096 bytes can handle those torrents.  The uploader may have created their torrent on a Linux system without testing the torrent on Windows and MacOS and have released their torrent, thinking that it is hunky-dory.

So, it is not just a WIndows issue.  It is also problematic (albeit less so) for MacOS and (albeit very unlikely) for Linux.  One solution, as you suggest, is to approach Microsoft (and Apple).  A second solution is to approach the uploader.  But that might not be so easy, since the uploader may not be the torrent creator.  The 3rd solution is for a workaround in Bitcomet.

Don't you want Bitcomet to be the GOAT?  Don't you want Bitcomet to be able to handle all torrents on both Windows and MacOS?  This will be my last message on this topic, I promise.  Good night and good luck.

Link to comment
Share on other sites

It's simple - Windows doers NOT handle long file/path names well.  It's a known issue in the OS and NOTHING to do with Bitcomet

'Fixing' something in the OS is NOT something the devs would do (even if they could)

You have been told repeatedly that it's not a BitComet issue so, PLEASE, stop asking for a 'fix'

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...