Speaking of resizing partitions, can Partition Logic or any other tool you know of resize a NTFS partition to the left without moving all its data to the left?

See detail discussion here (http://reboot.pro/14823/), if needed. And may be you can comment in that thread, exactly why it can or can't.

Hello, I had a look at the thread. The explanation "extra programming required" partly captures the problem, but also consider the added complexity of implementing both kinds of resizing. Resizing a filesystem reliably can be a very tough programming problem, and picking a single way to go about it, rather than 2 ways (expanding or contracting from the end of the filesystem, for example) is the most logically simple way to go about it - especially if it can be done without moving much data around. Resizing from the front would require, for most filesystems, moving lots of metadata around and then changing it completely, since the clusters/inodes/etc numbers would *all* change relative to the start of the filesystem. If you resize from the end, then often a smaller number of things need to be changed.

Complexity is an important factor. When you get it wrong, as a programmer (even a little bit) you can screw up peoples' data. Those aren't nice emails to receive, I can assure you.

Moving the partition to the 'left' before expanding the filesystem is just a simple data copy -- resource/time intensive, yes, but generally safe. From my perspective, data safety is the most important thing.

You have a chance to offer a unique product - none of paid for Partition Managers offer such feature. I have to assure you - its very sensible issue, given low reliability of today's large drives, and their limited lifespan resource. I opted several times to leave an unused empty partition in front of my 2Tb large data partition with movies, since copying senselessly this data closer to drive start would decrease service life of the drive (given my experience with other similar drives). This is not only about resource load, but also about associated costs and consequences. It's not theory - it's unfortunate reality.

Besides, when you tell "to copy is safe", you simply mean, MS code will do very same job as you described above instead of your program. May be its more reliable because someone else extensively tested the code and can be named responsible for failure, unless you can make it of similar stability. BTW, for several years I never extended a partition to the left only because of this reason - too high load to the drives for no reason. I'm sure, many ppl can't use a lot of free drive space because of that. To understand me better, just look at Seagate forums - ppl return large share of new drives due to limited lifespan and frequent failures. Programs like yours should not contribute or accelerate physical drive damage, when simpler, smarter, more economical ways to do the same job are long overdue.

You have a chance to offer a unique product - none of paid for Partition Managers offer such feature. I have to assure you - its very sensible issue, given low reliability of today's large drives, and their limited lifespan resource. I opted several times to leave an unused empty partition in front of my 2Tb large data partition with movies, since copying senselessly this data closer to drive start would decrease service life of the drive (given my experience with other similar drives). This is not only about resource load, but also about associated costs and consequences. It's not theory - it's unfortunate reality.

Moving a partition's data is a one-time operation (you only read and write each sector once). I guess I don't really understand the risk here. If disks are really that delicate, then we have a much larger problem than that posed by the occational partition resizing operation.

sambul14 wrote:

Besides, when you tell "to copy is safe", you simply mean, MS code will do very same job as you described above instead of your program. May be its more reliable because someone else extensively tested the code and can be named responsible for failure, unless you can make it of similar stability.

No, I mean that copying data is safe because it doesn't involve recomputing all the offsets, etc. If you ask any developer of partitioning software, they'll tell you the same. 'Moving' a partition is computationally trivial, and thus 'safe'. Resizing a partition is a very complicated and dangerous operation. Any programming error can render entire filesystems unusable, and all the data lost. Writing code to resize filesystems from both the front and the back involves a lot of extra code, and thus increases the likelihood of bugs (and data loss). Resizing filesystems from the end is typically simpler, and involves less of the "wear and tear" on the drive that you're worried about (recalculating all the metadata). If the partition also has to be moved, yes, that's addidional time and I/O, but it's a simple operation.

Well, I assume resizing a partition from the back is trivial since there is no data to care about. Meaning it entails low risk, but from algorithm and computational standpoint there shouldn't be much difference, since both methods would presume similar calculations. Hence, it shouldn't be that hard to develop a single universal algorithm that would use a switch invoked depending on resizing direction. Maintenance volume will remain the same, but number of grateful users will grow exponentially, given costs of ongoing failed HD replacements and absolute lack of competitors.

Consider yourself a pioneer in this field. What you're going to loose by offering a free product with far more advanced features than your competitors? You can go through careful alpha and beta stages, and worn users as appropriate to avoid angry emails.

Don't copy your competitors - try to lead instead by capitalizing on your program fans' feedback.

Well, I assume resizing a partition from the back is trivial since there is no data to care about.

Absolutely not true! Shrinking can involve moving lots of data, and both shrinking and expanding involve moving and resizing areas of metadata (think $logs and journals, FAT tables, etc) which also involves moving user data around.

Nothing about resizing filesystems is trivial!

sambul14 wrote:

<snip>Don't copy your competitors - try to lead instead by capitalizing on your program fans' feedback.

That's good advice, thank you. I always try to pay attention to what users want, and focus on the things that matter the most to the largest numbers of users. This is the first time I've been asked about this particular issue.

Thanks for your friendly attitude and attention to detail. However, the problem isn't new no matter how you look at it. Just follow this thread on Gparted forum to see similar kind of "too much work...don't bother" explanation provided on exactly same question of another user. Keep in mind, many Partitioning tool users are not prepared enough to realize implications, but regardless they all suffer consequences of non-justified moving of huge data massive around. I catched it long time ago, while loosing data to failed drives, and avoided resizing to the left since then. If you look at other similar tool forums, sure you will find same user feedback that was either ignored by large companies like Paragon to cut costs, or a smaller company get afraid of doing some work no-one accomplished before.

You offer a good tool, and appear to be pleasant, knowledgeable and interested person. Sure you'll find the best approach to tackle the issue if interested to - with no impact on program stability. It might not be that much coding involved in resolving the task, but simply management of large corporations don't want to spend extra funds on tackling that. As an example, sure you use Adobe Acrobat, and noticed they removed multiTab UI from it to cut dev costs despite very loud user demand and hefty prices. Read their forum, overflown with angry user feedback to no avail. And those are all paid customers and admins.

Your approach seems different, and this task presents a unique opportunity to master your skills and make a notable contribution to re-partitioning efficiency. Everyone will notice as soon as you notify and educate users about the resolved issue. Btw, discussion on Reboot.pro will continue, and more details and arguments to be presented. That forum is extremely popular - the ideal way to promote your tool by grateful users, if you fix the issue.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum