[Bug 1049003] New: Repeated directory/data loss when moving USB drives between openSUSE Leap 42.2 and Windows 8.1/10
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003 Bug ID: 1049003 Summary: Repeated directory/data loss when moving USB drives between openSUSE Leap 42.2 and Windows 8.1/10 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: Greg.Freemyer@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Build Identifier: I've had severe data loss on external USB drives happen 4 or 5 times now n the last 6 months, and Leap 42.2 has been in the loop each time. (I did not use Leap 42.1 extensively in this manner, so I have no relevant comments about it in this regard.) I do a very large amount of work on USB-3 drives both exclusively with Windows 8.1 connected drives and with USB-3 drives I originate in Leap 42.2. The drives that are exclusively used in Windows 8.1/10 have not experienced the problem I'm reporting here. Thus, even though the below doesn't seem to indicated Leap 42.2 is the source of the problem, I think it is . As a guess, this issue is happening on 10% or less of the filesystems I work with. == details == I often create numerous 1.5GB file in Linux to a USB-3 external drive then move the drive to Windows to work with. For some strange reason I've had several "lost directories full of files" in the last 6 or so months. I just had it happen again and maybe we can see what's going on. 1) I used a new from the box internal drive connected to a USB-3 / SATA adapter and connected it to a Leap 42.2 box. Via Leap I created a tradition partition table and made one large partition. I formatted the the partition NTFS via Leap (mkfs.ntfs -Q /dev/sdb1) 2) I used Leap to populate a directory full of 1.5GB files (500 GB total). All looked good. 3) I unmounted the drive from the Leap box and moved it to a Windows 8.1 box. 4) From Windows (at the time I could see the directory) I created an analysis project related to the 500GB of data and started processing the case. (So I know I could see the 500GB of data from Windows 8.1) That was done Friday. 5) I did some Windows patch updates and rebooted the PC. I didn't look at the drive over the weekend. 6) This morning, I want to continuing working the project, and the drive holding the 500GB of data looks basically empty. That's true in both Windows 8.1, Windows 10, and Linux. But in all 3 I have ~500GB of space unaccounted for. ie. Disk used + freespace is ~500GB less than the size of the file-system. 7) I throw the physical media into forensic data recovery tool (X-Ways) to take a look at the drive. 8) X-Ways shows me the missing folders and all 500GB of data and numerous other directories that are missing when looking at the drive natively as above (6). Obviously something is corrupt on the current drive. I have forensic tools that can let me look at filesystem metadata. I would report this upstream, but Leap 42.2 is using a version of NTFS-3G from 2013. I doubt upstream would be interested in a bug report. Reproducible: Sometimes -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003#c1
Andreas Stieger
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003
Andreas Stieger
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003
http://bugzilla.opensuse.org/show_bug.cgi?id=1049003#c2
--- Comment #2 from Greg Freemyer
I see that you are the openSUSE maintainer of ntfs-3g_ntfsprogs. So would you say that upgrading to a more recent version of ntfs-3g_ntfsprogs (thus moving away from the SLE package) fixes this?
I seem to be unable to locate the SLE bugowner for this package. This is certainly relevant for Desktop and Workstation Extension usage.
[Thanks for not assigning it back to me!] I suspect that a version upgrade may be too simplistic. For this use case, I used openSUSE 13.1 heavily in the same way until I jumped to 42.2 less than 6 months ago and I never had this problem. openSUSE 13.1 used the same ntfs-3g_ntfsprogs package that Leap 42.2 still does. I also have ruled out hardware because I have SuseStudio boot media based on Leap that I use on client PCs. Media created with that Leap based boot media has had the same problem even when client owned computers created the NTFS filesystem. Prior to 6 months ago, I was using a 13.1 based SuseStudio image without issues. So I don't really have a theory at this point, but I suspect mkfs.ntfs is the culprit. Maybe it doesn't work well with recent kernels? It actually makes no sense to me. My first local test will be to try the latest ntfs-3g_ntfsprogs from filesytems, unless someone has another suggestion? I'm only having this problem sporadically, so testing will be very slow. fyi: I have the most recent "data loss drive" in a filesystem analysis/data recovery tool (X-ways - a commercial tool) and it isn't reporting any problems and that the directory is present. I have the MD5 hash of the files from before the data loss, and the x-ways recovered files from the "data loss drive" have the correct hash. Whatever the problem is, it's subtle. The core problem might be a Windows change in the last 6 months. If so, it will only make sense to troubleshoot with the latest upstream version of ntfs-3g_ntfsprogs. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com