After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589008 - appear a bug when resize a fat16 system in a pendrive
appear a bug when resize a fat16 system in a pendrive
Status: RESOLVED DUPLICATE of bug 573190
Product: gparted
Classification: Other
Component: application
0.3.8
Other All
: Normal normal
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2009-07-19 10:05 UTC by alexelprogramador
Modified: 2009-08-11 18:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description alexelprogramador 2009-07-19 10:05:17 UTC
Please describe the problem:
Hello!

thanks 4 your work, I like your sofwarre GPARTED!

It appears a bug, when a resize a fat16 system from 4 gb to 700mb

I changed of o.s. and the problem continue

Its a pendrive:


Disk /dev/sdb: 4009 MB, 4009754624 bytes
255 heads, 63 sectors/track, 487 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         487     3911796    6  FAT16


Steps to reproduce:
1. ¿witch fat16 partitions?
2. 
3. 


Actual results:
gparted doesnt close, but it does a undo "makes as it was before"

Expected results:


Does this happen every time?
yes

Other information:
GParted 0.3.8

 Libparted 1.8.9

 
Shrink /dev/sdb1 from 3.73 GiB to 815.77 MiB  00:00:06    ( ERROR ) 
      
   calibrate /dev/sdb1  00:00:00    ( SUCCESS ) 
      
  path: /dev/sdb1
start: 63
end: 7823654
size: 7823592 (3.73 GiB) 
   calculate new size and position of /dev/sdb1  00:00:00    ( SUCCESS ) 
      
  requested start: 63
requested end: 1670759
requested size: 1670697 (815.77 MiB) 
  new start: 63
new end: 1670759
new size: 1670697 (815.77 MiB) 
   check filesystem on /dev/sdb1 for errors and (if possible) fix them  00:00:03    ( SUCCESS ) 
      
  dosfsck -a -w -v /dev/sdb1 
      
  dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
 512 bytes per logical sector
 65536 bytes per cluster
 1 reserved sector
First FAT starts at byte 512 (sector 1)
 2 FATs, 16 bit entries
 122368 bytes per FAT (= 239 sectors)
Root directory starts at byte 245248 (sector 479)
 512 root directory entries
Data area starts at byte 261632 (sector 511)
 61117 data clusters (4005363712 bytes)
63 sectors/track, 255 heads
 63 hidden sectors
 7823487 sectors total
Reclaiming unconnected clusters.
/dev/sdb1: 3022 files, 12756/61117 clusters
 
   shrink filesystem  00:00:00    ( ERROR ) 
      
   using libparted 
   check filesystem on /dev/sdb1 for errors and (if possible) fix them  00:00:03    ( SUCCESS ) 
      
  dosfsck -a -w -v /dev/sdb1 
      
  dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
 512 bytes per logical sector
 65536 bytes per cluster
 1 reserved sector
First FAT starts at byte 512 (sector 1)
 2 FATs, 16 bit entries
 122368 bytes per FAT (= 239 sectors)
Root directory starts at byte 245248 (sector 479)
 512 root directory entries
Data area starts at byte 261632 (sector 511)
 61117 data clusters (4005363712 bytes)
63 sectors/track, 255 heads
 63 hidden sectors
 7823487 sectors total
Reclaiming unconnected clusters.
/dev/sdb1: 3022 files, 12756/61117 clusters
 
   grow filesystem to fill the partition  00:00:00    ( ERROR ) 
      
   using libparted 
   libparted messages    ( INFO ) 
      
  There are no possible configurations for this FAT type. 
  The file system is bigger than its volume!
Comment 1 Curtis Gedak 2009-08-11 17:12:41 UTC
Thank you alexelprogramador for reporting this problem.

The source of the problem is the 4 GB FAT16 file system.  Prior to Windows NT, the maximum size of a FAT16 file system was 2 GB.  Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned.  This change is incompatible with the previous generations of DOS and Windows.

You can read more about FAT16 file systems at:
http://en.wikipedia.org/wiki/File_Allocation_Table

GParted uses the libparted library from the parted project to manipulate partitions.  Recently, the Parted project released version 1.9.0 that includes a patch to handle FAT16 file systems with a 64 KB cluster size.
You can read more about the parted-1.9.0 release at:
http://lists.gnu.org/archive/html/bug-parted/2009-07/msg00005.html

The first Live distribution that I am aware of that packages parted-1.9.0 with gparted-0.4.6 is the System Rescue CD.  Specifically SystemRescueCd-x86-1.2.3.


Would you be able to download this System Rescue CD to test if this problem is now solved?
Comment 2 Curtis Gedak 2009-08-11 18:50:24 UTC
After looking through the bug logs, I found that this problem was previously reported.  I tested and confirmed that the problem is fixed in parted-1.9.0.  Hence I am marking this bug as a duplicate of the previous one.


*** This bug has been marked as a duplicate of 573190 ***