Jump to content
Comet Forums
Sign in to follow this  
Malgoth

Large files on non-NTFS partition

Recommended Posts

Got an issue when trying to download large files with Bitcomet 1.17. When opening a torrent file and choosing destination directory is says: "File to be downloaded is larger than 4GB, please modify your destination location to NTFS...". Okey-dokey! I know that FAT32 doesn't support files larger than 4GB, but the thing is I'm using an EXT3 (for network media player) formatted HDD partition which is connected to Windows XP OS via Ext2Fsd utility. Windows recognizes it correctly (like an ordinary FAT32 or NTFS local drive in "My Computer") and says it is EXT3 partition in its properties.

SO, it would be really nice if in such cases (file(s) >4GB in torrent) Bitcomet could check whether the destination file system really is FAT, FAT32 or any other FS that doesn't support large files and only then give an advice to change FS.

Share this post


Link to post
Share on other sites

Filesystems do not generally report their own parameters and limitations. That is, Win98 does not say, "I don't support files larger than 4GB.".

Rather, this is extrinsic knowledge -- you (as a programmer) just have to know that. The way Windows applications do this is to ask what the filesystem is mounted as. It can only handle a few answers. If the answer is not NTFS, then it must be one of the other two filesystems extrinsically known about, which are extrinsically known not to support files this large.

Likewise, since filesystems do not report this, applications do not query about it. One cannot ask, through an OS call, what the maximum filesize supported is. There is no common mechanism to ask, and no common mechanism to answer, this query. Not much need, since most OS's can't even communicate with most filesystems to ask any questions in the first place.

It follows that unless BitComet and other applications are charged with supporting every new and fringe OS in existence (they aren't, they won't, kthxbye), then it is up to the operating system in question to supply answers to the questions applications CAN ask (like, what OS are you?), that allow operations to continue.

Very, very few applications are going to be able to handle an answer like, "I'm Ext2Fsd, thanks for asking!" in a usable way. Unless Ext2Fsd becomes so extremely mainstream that it actually gets Windows support (Mac can't, OS/2 can't unix can't, even Netware can't) for some reason, it's unlikely that most applications ever will support it or other fringe OS filesystems. If Ext2Fsd cannot handle this environment, it cannot handle Windows, nice try, next contestant, please.

It's going to be up to Ext2Fsd to answer, "Yes, I am NTFS", to that question in order for the vast majority of applications not to choke on the answer.

To put it another way, Windows doesn't natively support any of these other file systems, all of which are in far wider use than Ext2Fsd. So hold not thy breath.

BitComet does not work on the requisite level to bypass filesystem commands and do raw disk access for other filesystems. It uses Windows to do that, and the developers are unlikely to rewrite enough of the basic OS to intervene at those levels. If they wanted to work on filesystem internals they probably wouldn't be working for BitComet. BC will be able to do it when Windows is able to do it. Windows still hasn't natively gotten around to NWFS yet.

Share this post


Link to post
Share on other sites
If the answer is not NTFS, then it must be one of the other two filesystems extrinsically known about, which are extrinsically known not to support files this large.

That's the way Bitcomet works now and it can go wrong sometimes (well, at least in my case it does :) ). I suggest not to check whether the destination file system for the large file is NTFS and then decide it must be FAT16 or FAT32 only, but instead of this check whether it is FAT16 or FAT32 and if not - allow torrent task to start. In this way nothing is changed for these 3 native Windows file systems but allows in cases like mine to get the things done.

Or at least make some advanced option to ignore this 'Non-NTFS'-warning...

BitComet does not work on the requisite level to bypass filesystem commands and do raw disk access for other filesystems. It uses Windows to do that, and the developers are unlikely to rewrite enough of the basic OS to intervene at those levels. If they wanted to work on filesystem internals they probably wouldn't be working for BitComet. BC will be able to do it when Windows is able to do it. Windows still hasn't natively gotten around to NWFS yet.

Thats what I'm trying to say! No need for Bitcomet to get raw disk access or something - with Ext2Fsd Windows handles EXT2/EXT3 partitions as easy as its native FAT/NTFS.

post-55932-126297370268.png

No need for Bitcomet event to know about the Ext2Fsd running - just start the torrent task and Windows will store the files on this partition just perfectly!

Share this post


Link to post
Share on other sites

That's the way Bitcomet works now and

No, that's the way Windows works now. BC just makes calls into the windows file system at a much higher level. It does NOT make low-level OS calls or attempt to bypass same.

No need for Bitcomet event to know about the Ext2Fsd running - just start the torrent task and Windows will store the files on this partition just perfectly!

BitComet does not know.

BitComet only knows what it's told by Windows, namely that this is not an OS which supports large files.

BitComet doesn't make that judgment call. Windows does. BC proposes to write a file larger than 4GB to the disk, and the operating system returns an error, which BC interprets for you as the message you saw.

BitComet does not get involved in filesystem operations on that level.

It is going to be up to Ext2Fed to work out an accomodation with windows, to present itself as NTFS in order to work around this. BitComet cannot adapt to it short of bypassing the Windows disk handling and taking care of that itself. This isn't going to happen.

Ext2Fed must change, must adapt to Windows. Windows isn't going to adapt to it. You are wasting your time trying to pursue this as a change to BitComet.

Share this post


Link to post
Share on other sites

No, that's the way Windows works now. BC just makes calls into the windows file system at a much higher level. It does NOT make low-level OS calls or attempt to bypass same.

To me the conversation between BC & Windows is like this:

BC: Large file in the torrent. Hey, Win, what's the file system of the destination partition and is there enough free space?

Win: FS is EXT3, enough free space.

BC: <_< uh... what's that? Oh, never mind, you Win can only handle large files with NTFS and this must be some kind of a FAT16 or FAT32 :D

Win: Well, actually it's not, and I can...

BC: No, you can not, Win B) Hey, user, give me NTFS for this torrent!

And some prove is on the way...

For example, Total Commander (and any other Windows file manager) works with Ext2Fsd-mounted EXT3 partition and large files on it just perfectly (I:\ is an EXT3 partition):

post-55932-126304895005.png

But let's try something more relevant to BitComet like µTorrent :rolleyes:

Adding a torrent with a large file to a EXT3 as a destination:

post-55932-126304924837.png

Starting the task:

post-55932-126304928773.png

Works OK... Strange, isn't it? :rolleyes:

Checking the file in the destination dir:

post-55932-126304943239.pngpost-55932-126304949541.png

No errors, no "give-me-NTFS" demands, works just as it should.

The very same torrent in BC - and you already know what the result will be!

post-55932-126305023544.png

BitComet doesn't make that judgment call. Windows does. BC proposes to write a file larger than 4GB to the disk, and the operating system returns an error, which BC interprets for you as the message you saw.

But why doesn't OS return any errors to Total Commander, µTorrent or any other application? Or would you say they all perform that low-level disk access bypassing Windows HDD managment? :lol: There would be no need for Ext2Fsd then.

BitComet cannot adapt to it short of bypassing the Windows disk handling and taking care of that itself.

There's no need for this! All the troubles come just of BC's logic: "Large file on non-NTFS? Won't even try and ask Windows if it can handle this!"

Share this post


Link to post
Share on other sites

Maybe I'm wrong with my inferences ;)

So, any suggestions why µTorrent works OK in this situation and BitComet doesn't? :wacko:

Share this post


Link to post
Share on other sites

µtorrent simply doesn't ask. (You don't have to.) And when it doesn't work, µtorrent cheerfully runs off the rails.

I hung on to Win98 for a long time past its sell-by date, on a dual-boot system. (I still dual-boot Win2k).My largest partition then was FAT-32, and I started µtorrent to downloading the several DVD iso's of Myst: Uru. The disk images were > 4GB, but I'd forgotten about that limit. µtorrent cheerfully started the download, then just abruptly choked with a disk error when the file tried to grow larger than 4GB.

µtorrent left it to me to figure out why it had just stopped and couldn't write to the disk. (It was this incident that finally got me to embrace XP, though 2K was still my primary OS. Funny, but I didn't even like Uru as it turned out.)

They're both valid (for some value of valid) ways of handling the issue. It's your choice, but I druther have BitComet's way, "doesn't look like this will work", than µtorrent's stoner-like, "it broke, d00d, dunno what's wrong...".

Share this post


Link to post
Share on other sites

µtorrent simply doesn't ask. (You don't have to.) And when it doesn't work, µtorrent cheerfully runs off the rails.

That's not true. For the latest stable release version 1.8.5 if you try to start a >4Gb-file task on a FAT32 partition, you'll get this:

post-55932-126376227567.png

I hung on to Win98 for a long time past its sell-by date, on a dual-boot system. (I still dual-boot Win2k).My largest partition then was FAT-32, and I started µtorrent to downloading the several DVD iso's of Myst: Uru. The disk images were > 4GB, but I'd forgotten about that limit. µtorrent cheerfully started the download, then just abruptly choked with a disk error when the file tried to grow larger than 4GB.

µtorrent left it to me to figure out why it had just stopped and couldn't write to the disk. (It was this incident that finally got me to embrace XP, though 2K was still my primary OS. Funny, but I didn't even like Uru as it turned out.)

That could happen with the early versions of µt, but from that days they have worked on this issue for sure :)

They're both valid (for some value of valid) ways of handling the issue. It's your choice, but I druther have BitComet's way, "doesn't look like this will work", than µtorrent's stoner-like, "it broke, d00d, dunno what's wrong...".

This is where we come again to your previous statement:

BitComet doesn't make that judgment call. Windows does. BC proposes to write a file larger than 4GB to the disk, and the operating system returns an error, which BC interprets for you as the message you saw.

I just tried to copy a 5Gb image file in Windows Explorer (I mean this native file manager) to a FAT32 partition with enough free space and, as expected, got this error fat32-error-message1.jpg

That's the error you are talking about. But there aren't any errors if you try to copy it to NTFS or EXT3 partition in the same Windows Explorer!

And all I'm asking is to really make BitComet work the way you described above: "BC proposes to write a file larger than 4GB to the disk, and the operating system...". Let BC offer the OS to write a large file! If the OS returns an error like it does in case of FAT32, then stop, but if it doesn't - let the OS do the job!

Share this post


Link to post
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.

Guest
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.

Sign in to follow this  

×
×
  • Create New...