Searching for info regarding autosplit of files >4GiB on FAT32 partitions
Hi everybody!
I opened this thread because I'm looking for hints/suggestions on adding an auto-split functionality when copying files bigger than X bytes on a filesystem which supports only single files not bigger than X bytes. While the problem is kinda generic, the more common example would be files > 4GiB to be copied on a FAT32 partition, so I put that in the title of the thread. I will start explaining what I'd like to achieve and what ideas I have at the moment. Objective To be able to copy a file of over X bytes size on a partition which supports only single files not bigger than X bytes transparently to the user. I often stumble upon this missing feature when copying recordings of TV shows from my PC (after having cut off commercials) to a FAT32-formatted USB thumbdrive. I perfectly know how to manually split those files, but I'd like to come together with an automated generic solution, which should be able to work equally across different desktop environments. To sum it all up, the solution should:
Implementation ideas Here are some possible implementation ideas I've come up with (still very high level): Kernel based implementation I'm not very acquainted with kernel development and I know very little of its low-level architecture, but I'd guess that to implement this auto-split functionality one would need to modify filesystem code (namely the vfat source code for FAT32 filesystems) to add the required functionality, but it wouldn't be a good idea because of the external tools needed for some splits, which could hinder the security of the system. Some kind of "hook" inside filesystem code which gets called every time a copy operation is performed could be a better approach, but I think it implies an interface change for a lot of code, making it impractical. FUSE based implementation Other ideas could be:For what I've seen in some tutorials/documentation (but I may have overlooked the important parts), FUSE allows to create filesystem drivers in userspace, but it doesn't allow to extend an existing filesystem (namely, vfat) with additional functionality. A FUSE filesystem needs to be mounted too, so some "transparency points" are lost :)
Thanks for reading all of this :) |
I think you only need a special user space copy which will be able to recognize the underlining filesystem and based on that info will split "on the fly". I do not think you would need to implement kernel module or similar, just a shell script.
|
Hi there,
Quote:
Quote:
Quote:
I'd rather favor a file type independent solution: A special copy handler that encapsulates the file into another container format. A proper file name extension, a few bytes allowing safe recognition and a header containing information like full file size should be enough. In the reverse direction, this copy handler must be able to recognize the container and recreate the original file (maybe even prompt you to change CDs). When I think about it, I see that this is very much like the way popular archiving tools work ... [X] Doc CPU |
Quote:
Quote:
Maybe this kind of operation is better done via a CD/DVD burning software, which could better manage media insertions/removals for the splitting. Quote:
Quote:
Still thinking at the problem at a very high level, one can assume that this special copy handler could work like this:
In this way, you can perform simple splits for all the files (if no "rules" are loaded) or let the "rules" manage the split Quote:
By the way, thanks pan64 and Doc CPU for these initial comments. |
All times are GMT -5. The time now is 10:13 AM. |