Menu
▾
▴
ntfs-3g-devel — Development discussion and problem submission
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(47) |
Dec
(49) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(53) |
Feb
(43) |
Mar
(38) |
Apr
(25) |
May
(35) |
Jun
(18) |
Jul
(9) |
Aug
(12) |
Sep
(29) |
Oct
(43) |
Nov
(65) |
Dec
(14) |
| 2008 |
Jan
(28) |
Feb
(24) |
Mar
(54) |
Apr
(40) |
May
(63) |
Jun
(5) |
Jul
(26) |
Aug
(10) |
Sep
(4) |
Oct
(8) |
Nov
(10) |
Dec
(5) |
| 2009 |
Jan
(17) |
Feb
(4) |
Mar
(23) |
Apr
(9) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(16) |
Nov
(8) |
Dec
(38) |
| 2010 |
Jan
(15) |
Feb
(5) |
Mar
(1) |
Apr
|
May
(4) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(14) |
Oct
(5) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(8) |
Aug
(13) |
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(6) |
| 2012 |
Jan
(3) |
Feb
(9) |
Mar
|
Apr
(4) |
May
|
Jun
(35) |
Jul
(14) |
Aug
(1) |
Sep
|
Oct
(16) |
Nov
|
Dec
|
| 2013 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(9) |
Sep
(15) |
Oct
(3) |
Nov
(5) |
Dec
(18) |
| 2014 |
Jan
(5) |
Feb
(5) |
Mar
(7) |
Apr
(8) |
May
|
Jun
|
Jul
(27) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(12) |
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(39) |
Dec
(10) |
| 2016 |
Jan
(22) |
Feb
(32) |
Mar
(4) |
Apr
(48) |
May
(14) |
Jun
(7) |
Jul
(19) |
Aug
(5) |
Sep
(16) |
Oct
(12) |
Nov
(2) |
Dec
(2) |
| 2017 |
Jan
(14) |
Feb
(38) |
Mar
(13) |
Apr
(7) |
May
(7) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2018 |
Jan
(4) |
Feb
|
Mar
|
Apr
(7) |
May
(4) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2019 |
Jan
(47) |
Feb
(2) |
Mar
|
Apr
|
May
(3) |
Jun
(18) |
Jul
(1) |
Aug
(5) |
Sep
(9) |
Oct
(6) |
Nov
(5) |
Dec
|
| 2020 |
Jan
|
Feb
(16) |
Mar
(16) |
Apr
(6) |
May
|
Jun
(2) |
Jul
(5) |
Aug
(14) |
Sep
(9) |
Oct
(14) |
Nov
(5) |
Dec
(1) |
| 2021 |
Jan
(19) |
Feb
(7) |
Mar
(7) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(11) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pete B. <pe...@ak...> - 2021-03-20 03:11:15
|
Hi, I have just completed a fork of ntfs-3g that adds support for building the project as UEFI driver. As such, I would very much like to see this feature included in mainline, especially I have taken great care to break down the commits into a patch series that should facilitate its review for integration. You can find the fork at: https://github.com/pbatard/ntfs-3g You can also find the ~65 commits that are needed to add UEFI driver support starting around https://github.com/pbatard/ntfs-3g/commits/uefi-driver?after=0e160412aa15b51f700c6d7f1175abba39233d3c+34&branch=uefi-driver. With these patches applied, one can use the ntfs-3g source to build a UEFI NTFS driver, for all the mainline UEFI architectures (X64, IA32, AARCH64, ARM) on either Linux or Windows, through a gcc/EDK2 toolchain (Linux) or a VS2019/EDK2 or VS2019/gnu-efi toolchain (Windows). You can also find a very concrete example of how one can produce such a build on Ubuntu through the AppVeyor build log at https://ci.appveyor.com/project/pbatard/ntfs-3g?fullLog=true, which details how we produce our current binary releases (that are also currently found at https://github.com/pbatard/ntfs-3g/releases). Furthermore, regardless of UEFI interest, I believe that our fork does provide some features that mainline might want to consider for integration, such as enabling one-shot mode for readdir (so that one can halt the call after one entry has been processed and actually resume the listing from the returned position) or static asserts in layout.h (which can be an invaluable help when adding support for a new platform or new toolchains, as it validates that the structure mapping does match the NTFS requirements). A detailed breakdown of the patch series is as follows: * Patches 0001-0009 are mostly about fixing header issues, that may not have been apparent when creating executables for POSIX OSes, but that are a real problem when doing so for other OSes or low level UEFI. * Patch 0010 fixes configure's --enable-debug option, which currently does not translate to anything useful, in order to pre-emptively address a conflict with the EDK2's DEBUG() macro. * Patch 0011 adds a new option to force UTF-8 usage everywhere, required for UEFI, as there is no such thing as POSIX-like locale support there. * Patch 0012 adds NTFS volume serial number retrieval, which, while easy to populate, was strangely missing from ntfs-3g. This is another requirement for UEFI, as we need to be able to detect volume removal/change, where the ability to check a volume serial becomes crucial. * Patches 0013, as well as 0027-0033 deal with improving/fixing compatibility of the codebase for MSVC compilers, as it is understandably currently skewed towards to the use of gcc-like compilers, and some of the gcc-isms don't sit too well with MSVC. * Patches 0014-0017 start to handle UEFI specifics, with patch 0015 actually adding an initial dummy UEFI driver, that of course doesn't do much of anything except loading/unloading, but can be built with the EDK2. On that subject, it needs to be pointed out that the EDK2 has a fairly "rigid" way of producing executables (you can't use configure/make, but have to provide the .inf/.dsc/.dec/.uni files that the toolchain expects) with some restrictions with regards to the location of some of the files This is the reason why the uefi-driver.dec and uefi-driver.dsc files must reside at the top level of the repository, and cannot be "hidden" in the uefi-driver/ folder. * Patch 0018 and 0020 fix conflicts between some elements that are really handled as the same thing by EDK2 and ntfs-3g, but aren't seem the same, on account of compiler pedantry. * Patches 0019 and 0021-0026 and 0034-0037 deal mostly with adding the required UEFI support functions to ntfs-3g * Patches 0038-0047 relate to fleshing out the UEFI driver (there are quite a few API layers to go through), until it can actually start to call into libntfs-3g. * Patch 0048 adds the UEFI I/O support layer to libntfs-3g, * Patches 0049-0051, with 0050 being the one that adds generic static assert support to ntfs-3g, have to do with ensuring that MVSC does pack the layout structures properly. * Patches 0052-0055 simplify readdir and add a "one-shot" mode, where returning a positive value in the filldir callback suspends readdir operation (which returns with a pos value pointing to the next entry), so that the listing can be continued in a subsequent call. The reason why we need a "one-shot" feature is that the UEFI expects repeated formal API calls (not callbacks) for each directory entry, which, if we didn't modify readdir, would force us to either issue a complete directory listing for each entry we want to process or cache entries, which isn't too great in terms of performance. * Patches series 0056-0058 and 0059-0062 finalize the UEFI driver for read-only and read/write operations respectively. After that comes a series of 6 patches that I have tagged "(OPTIONAL)", though I really would like to see at least 2 of those (VS2019 project support and CompilersIntrinsicsLib) to be considered for formal inclusion in ntfs-3g mainline, as these can be rather crucial for people who are interested in building the UEFI driver. * Patch 0063 adds an implementation of debug_double_inode(), which I heavily relied on during testing of the driver, as ntfs-3g is rather adamant that an inode should not be opened twice, whereas the UEFI shell default behaviour makes no qualms about reopening the same file many times over. On that subject, I should point out that a lot of the complexity of the UEFI driver has to do with trying to avoid double inode opening, with NtfsMoveFile() in uefi_bridge.c being quite the challenge to get right... * Patch 0064 adds a non GPLv2 (BSD-2-Clause-Patent) CompilerIntrinsics library, without which it is currently not possible to build the X64 or IA32 versions of the driver when using EDK2/MSVC. This library basically deals with providing basic compilers intrinsics (low level div/mul + some memory calls that the compiler insists on handling as intrinsics) that cannot easily be defined in the ntfs-3g code. And whereas each of these calls is rather short (though some contain assembly), it didn't really make sense for us to rewrite a GPLv2 version when we could just pick an existing BSD-2 implementation (which, per [1], is compatible with GPLv2), though of course this means that we need to convey that the this library is under a different license (which the patch does). Despite the additional license, considering that not having this patch makes EDK2 compilation on Windows impossible for X64 and IA32, I would very much like to see it integrated. * Patch 0065 adds gnu-efi as a submodule. gnu-efi [2] is a much leaner alternative to EDK2, that can make the process of building UEFI executables a lot less daunting for people who don't already have experience with tianocore/EDK2. Especially, since it integrates well with Visual Studio, it can lead to a complete turnkey solution, where Windows users just have to open the project, after having cloned ntfs-3g along with its submodules, to be able to both build and test the driver by pressing VS2019's "Debug" button. * Patch 0066 adds the Visual Studio 2019 project files. This is the second "optional" patch that I would really like to see considered for inclusion, as, perhaps to the future despair of current ntfs-3g project maintainers, I suspect that quite a few folks will be interested in being able to build the UEFI driver through Visual Studio, and I certainly would hate to have invested as much time as I did, ensuring that ntfs-3g and Visual Studio can play nice together, to have this patch left aside. * Patches 0067 and 0068 relate directly to the GitHub fork, and the provision of pre-built binaries thus, unless ntfs-3g is actively considering moving its whole project from SourceForge to GitHub, these can be safely left out. If you are interested in integrating these changes, I can send 0001-0066 as a formal patch series to this mailing list. Or I can sort something in the SourceForge project, if you prefer. But again, because a read/write UEFI NTFS driver is something that a lot of people have been asking for (which I can vouch for, as I been providing an alternate *read-only* version of such a driver for some time, based on GRUB 2.0, at https://efi.akeo.ie) and also because EDK2/UEFI doesn't seem to be moving towards providing an implementation, despite counting multiple Microsoft developers as formal contributors, I do think that it makes a lot of sense for ntfs-3g to want to officially support UEFI as another platform. As such, I am really hopeful that the ntfs-3g project maintainers will be interested in integrating these changes into mainline. Of course, I will be happy to answer any question you might have related to this proposal. Regards, /Pete [1] https://en.wikipedia.org/wiki/BSD_licenses [2] https://sourceforge.net/projects/gnu-efi/ |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-03-19 08:42:09
|
je...@ao... wrote on 3/19/21 7:03 AM: > Greetings, > > While building NTFS-3G, I found that despite specifying > --sbindir=/usr/bin, a good few executables are still installed in > /usr/sbin. Grepping around the tree, it seems that in many Makefile.am, > `/sbin' is specified as hard-coded paths. > > A list of offending Makefile.am are as follows: > > ntfsprogs/Makefile.am: $(RM) -f $(DESTDIR)/sbin/mkfs.ntfs > src/Makefile.am: $(MKDIR_P) "$(DESTDIR)/sbin" > src/Makefile.am: $(LN_S) -f "$(rootbindir)/ntfs-3g" > "$(DESTDIR)/sbin/mount.ntfs-3g" > src/Makefile.am: $(LN_S) -f "$(rootbindir)/lowntfs-3g" > "$(DESTDIR)/sbin/mount.lowntfs-3g" > src/Makefile.am: $(RM) -f "$(DESTDIR)/sbin/mount.ntfs-3g" > "$(DESTDIR)/sbin/mount.lowntfs-3g" AFAIK /sbin is hardcoded in mount(8). Quoting from the manual : "In order to make it possible to treat all types in a uniform way, mount will execute the program /sbin/mount.type (if that exists) when called with type type". mkfs.ntfs might however be located elsewhere. Jean-Pierre > > Best Regards, > Mingcong Bai |
|
From: <je...@ao...> - 2021-03-19 06:23:25
|
Greetings, While building NTFS-3G, I found that despite specifying --sbindir=/usr/bin, a good few executables are still installed in /usr/sbin. Grepping around the tree, it seems that in many Makefile.am, `/sbin' is specified as hard-coded paths. A list of offending Makefile.am are as follows: ntfsprogs/Makefile.am: $(RM) -f $(DESTDIR)/sbin/mkfs.ntfs src/Makefile.am: $(MKDIR_P) "$(DESTDIR)/sbin" src/Makefile.am: $(LN_S) -f "$(rootbindir)/ntfs-3g" "$(DESTDIR)/sbin/mount.ntfs-3g" src/Makefile.am: $(LN_S) -f "$(rootbindir)/lowntfs-3g" "$(DESTDIR)/sbin/mount.lowntfs-3g" src/Makefile.am: $(RM) -f "$(DESTDIR)/sbin/mount.ntfs-3g" "$(DESTDIR)/sbin/mount.lowntfs-3g" Best Regards, Mingcong Bai |
|
From: <je...@ao...> - 2021-03-19 06:18:34
|
Greetings, While building NTFS-3G, I found that despite specifying --sbindir=/usr/bin, a good few executables are still installed in /usr/sbin. Grepping around the tree, it seems that in many Makefile.am, `/sbin' is specified as hard-coded paths. A list of offending Makefile.am are as follows: ntfsprogs/Makefile.am: $(RM) -f $(DESTDIR)/sbin/mkfs.ntfs src/Makefile.am: $(MKDIR_P) "$(DESTDIR)/sbin" src/Makefile.am: $(LN_S) -f "$(rootbindir)/ntfs-3g" "$(DESTDIR)/sbin/mount.ntfs-3g" src/Makefile.am: $(LN_S) -f "$(rootbindir)/lowntfs-3g" "$(DESTDIR)/sbin/mount.lowntfs-3g" src/Makefile.am: $(RM) -f "$(DESTDIR)/sbin/mount.ntfs-3g" "$(DESTDIR)/sbin/mount.lowntfs-3g" Best Regards, Mingcong Bai |
|
From: - N. - <neu...@ho...> - 2021-02-24 19:06:46
|
Hello all, Tuxera team and all other contributors, NTFS-3G is a dead open-source project since several years: Four years in few days. Stable Source Release 2017.3.23: - https://www.tuxera.com/company/open-source/ Here it is empty: - https://sourceforge.net/projects/ntfs-3g/files/ Latest news in 2016: https://sourceforge.net/p/ntfs-3g/mailman/ntfs-3g-news/ I request an official organization/repositories for NTFS-3G on GitHub to have a new development: - One for the project sourcecode - One for the website sourcecode and to have a website hosted on GitHub Pages. I know this unofficial website here: https://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html Thanks in advance. Regards, Neustradamus |
|
From: Akshay A. <iam...@gm...> - 2021-02-24 09:15:22
|
Hi, I found this bug still exists in the latest version of ntfs-3g (ntfs-3g 2017.3.23AR.6 integrated FUSE 27). I have pushed the image here <https://github.com/r00tus3r/images/blob/master/loop.img> so that it might be easier for you to debug. Please let me know if you need any additional information. Thanks! Best, Akshay On Mon, Jan 11, 2021 at 8:25 PM Jean-Pierre André < jea...@wa...> wrote: > Akshay Ajayan wrote on 1/11/21 1:52 PM: > > Hi, > > > > I found the following bug while mounting a corrupt image using ntfs-3g. > > > > Bug info: > > Infinite loop in ntfs_volume_startup at volume.c:602 > > This bug occurs because of incorrect value of LCN of VCN 0 of the $MFT, > > image offset 0x30 in $Boot. > > Thank you for having already debugged the cause. > > I think I just have to add another condition in the consistency > check of the boot sector. > > And a reminder : there is a backup boot sector in the last sector > of the partition, it can be retrieved by ntfsfix when the normal > boot sector is corrupt. > > Jean-Pierre > > > > > Behavior in windows: Disk structure is corrupted and unreadable > > > > Version info: > > r00tus3r@akshay:~$ ntfs-3g --version > > ntfs-3g 2017.3.23 integrated FUSE 27 > > > > To Reproduce: > > ntfs-3g loop.img mountpoint > > > > Please let me know if you need the corrupted image file or any > > additional information. > > > > Best, > > Akshay > > > > _______________________________________________ > ntfs-3g-devel mailing list > ntf...@li... > https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel > |
|
From: Aniket P. <ann...@gm...> - 2021-02-24 06:52:24
|
Hi,
Recently while using ntfs-3g (2017.3.23AR.5) driver with the dedupe plugin
(1.2.5),
we encountered the following error while trying to read certain files on a
dedup mount.
[user@node-3 Desktop]$ file <REDACTED>.pdf
<REDACTED>.pdf: ERROR: cannot read (Operation not supported)
Mounting with the "debug" option and then retrying the above operation, we
got this error
in /var/log/messages:
[user@node-3 Desktop]$ sudo grep "ntfs-3g" /var/log/ -r
/var/log/messages:Feb 23 00:31:44 node-3 ntfs-3g[14691]: Unexpected dedup
format code 0x103
/var/log/messages:Feb 23 00:31:44 node-3 ntfs-3g[14691]: Unexpected dedup
format code 0x103
/var/log/messages:Feb 23 00:31:44 node-3 ntfs-3g[14691]: Unexpected dedup
format code 0x103
In the source code of dedup plugin there is this switch case for reparse
format code:
1377 /* Assume the format defines a minor.major type
version */
1378 switch (le16_to_cpu(dedup_reparse->format)) {
1379 case 0x0201 :
1380 res = dedup_read_short(ni, reparse,
1381 buf, size, offset);
1382 break;
1383 case 0x0102 :
1384 res = dedup_read_long(ni, reparse,
1385 buf, size, offset);
1386 break;
1387 default :
1388 ntfs_log_error("Unexpected dedup format code
0x%x\n",
1389
(int)le16_to_cpu(dedup_reparse->format));
1390 break;
We see that there are only two format codes at the moment, i.e 0x201 and
0x102. Can I get some help
regarding the third one (0x103), like what is it and how to reliably
reproduce and fix this issue?
I would appreciate any pointers for the same.
Thanks and Regards,
Aniket Pandey
|
|
From: Jean-Pierre A. <jea...@wa...> - 2021-02-23 15:10:10
|
Hi, Matthias Braun wrote on 2/23/21 1:23 PM: > Hi and thanks a lot for ntfs-3g! > > Since Windows Vista, formatting on Windows overwrites all data on the volume with zeros when doing a full format (as opposed to a quick format): https://docs.microsoft.com/en-US/troubleshoot/windows-server/backup-and-storage/format-command-not-write-zeros-to-disk > > What's the behavior of mkfs.ntfs in this regard on HDDs? Does it overwrite data outside the master file table? By default mkfs.ntfs (aka mkntfs) initially zeroes all the sectors before creating the file system tables. Doing so, bad sectors are detected and recorded so that they are not to be used subsequently. This can be avoided by setting the option --fast or --quick (see man mkntfs). > > When formatting an SSD with mkfs.ntfs, does it send an ATA TRIM command to the SSD to mark all the data as eligible for the SSD's garbage collector? Not currently, but you can use fstrim(8) afterwards for trimming the unused sectors of a SSD. Jean-Pierre > > Kind regards, > Matthias Braun > |
|
From: Matthias B. <mat...@bu...> - 2021-02-23 13:43:22
|
Hi and thanks a lot for ntfs-3g! Since Windows Vista, formatting on Windows overwrites all data on the volume with zeros when doing a full format (as opposed to a quick format): https://docs.microsoft.com/en-US/troubleshoot/windows-server/backup-and-storage/format-command-not-write-zeros-to-disk What's the behavior of mkfs.ntfs in this regard on HDDs? Does it overwrite data outside the master file table? When formatting an SSD with mkfs.ntfs, does it send an ATA TRIM command to the SSD to mark all the data as eligible for the SSD's garbage collector? Kind regards, Matthias Braun |
|
From: Richard W.M. J. <rj...@re...> - 2021-02-11 11:31:30
|
On Thu, Feb 11, 2021 at 10:27:06AM +0100, Jean-Pierre André wrote: > Hi Richard, > > [I quote your report here, as you wanted to do so, but faced some issue] > > >Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=211167 > >Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1926954 > >ArchLinux bug: https://bbs.archlinux.org/viewtopic.php?id=262243 > > > >fstrim of ntfs-3g filesystems is broken in newer Linux kernels. > > > >I have confirmed this and bisected it to a particular kernel commit: > > > > block: Do not discard buffers under a mounted filesystem > > Discarding blocks and buffers under a mounted filesystem is hardly > > anything admin wants to do. Usually it will confuse the filesystem and > > IMHO it is the admin job to optimize their system, even running 24/7. > > > sometimes the loss of buffer_head state (including b_private field) can > > even cause crashes like: > > So there is a missing serialization. It is each file system job > to make sure blocks are not reused or reallocated while they are > being discarded. > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 > > PGD 0 P4D 0 > > Oops: 0002 [#1] SMP PTI > > CPU: 4 PID: 203778 Comm: jbd2/dm-3-8 Kdump: loaded Tainted: G O --------- - - 4.18.0-147.5.0.5.h126.eulerosv2r9.x86_64 #1 > > Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015 > > RIP: 0010:jbd2_journal_grab_journal_head+0x1b/0x40 [jbd2] > > ... > > Call Trace: > > __jbd2_journal_insert_checkpoint+0x23/0x70 [jbd2] > > jbd2_journal_commit_transaction+0x155f/0x1b60 [jbd2] > > kjournald2+0xbd/0x270 [jbd2] > > So if we don't have block device open with O_EXCL already, claim the > > block device while we truncate buffer cache. This makes sure any > > exclusive block device user (such as filesystem) cannot operate on the > > device while we are discarding buffer cache. > > Reported-by: Ye Bin <ye...@hu...> > > Signed-off-by: Jan Kara <ja...@su...> > > Reviewed-by: Christoph Hellwig <hc...@ls...> > > [axboe: fix !CONFIG_BLOCK error in truncate_bdev_range()] > > Signed-off-by: Jens Axboe <ax...@ke...> > > > >As far as I can tell the commit is intended to stop you from doing > >blkdiscard on a block device which is in use by a (kernel) filesystem, > >which sounds like a good idea. Breakage of FUSE devices that use > >block devices is possibly an unintentional side-effect. > > So how is fstrim(8) supposed to be used ? Currently it requires a > mounted file system as its last argument. > > Technically ntfs-3g can close the device (without unmounting), reopen > it without O_EXCL for trimming, and reopen again with O_EXCL, but this > sounds like a very bad way of doing. > > How does the ext4 driver allow allow the discarding to take place ? I'm definitely not an expert here! However if you look at the problematic commit: https://github.com/torvalds/linux/commit/384d87ef2c954fc58e6c5fd8253e4a1984f5fe02 you'll see it only adds the new checks on the ioctl path, ie. when coming from userspace. I suppose that in-kernel drivers like ext4 would not use this code path so it wouldn't be a problem for them. I think it's just a kernel bug - they didn't anticipate the way that ntfs-3g or other FUSE filesystems implement fstrim. > Jean-Pierre > > > > >Although reverting the commit fixes it, I've no idea how to fix it > >properly. > > > >Rich. > > > >(BTW I'm unable to subscribe to ntfs-3g-devel ...) I think I was able to subscribe in the end. Hopefully this message will go through ... Rich. > >-- > >Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > >Read my programming and virtualization blog: http://rwmj.wordpress.com > >virt-builder quickly builds VMs from scratch > >http://libguestfs.org/virt-builder.1.html -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-02-11 09:27:29
|
Hi Richard, [I quote your report here, as you wanted to do so, but faced some issue] > Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=211167 > Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1926954 > ArchLinux bug: https://bbs.archlinux.org/viewtopic.php?id=262243 > > fstrim of ntfs-3g filesystems is broken in newer Linux kernels. > > I have confirmed this and bisected it to a particular kernel commit: > > block: Do not discard buffers under a mounted filesystem > > Discarding blocks and buffers under a mounted filesystem is hardly > anything admin wants to do. Usually it will confuse the filesystem and IMHO it is the admin job to optimize their system, even running 24/7. > sometimes the loss of buffer_head state (including b_private field) can > even cause crashes like: So there is a missing serialization. It is each file system job to make sure blocks are not reused or reallocated while they are being discarded. > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 > PGD 0 P4D 0 > Oops: 0002 [#1] SMP PTI > CPU: 4 PID: 203778 Comm: jbd2/dm-3-8 Kdump: loaded Tainted: G O --------- - - 4.18.0-147.5.0.5.h126.eulerosv2r9.x86_64 #1 > Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015 > RIP: 0010:jbd2_journal_grab_journal_head+0x1b/0x40 [jbd2] > ... > Call Trace: > __jbd2_journal_insert_checkpoint+0x23/0x70 [jbd2] > jbd2_journal_commit_transaction+0x155f/0x1b60 [jbd2] > kjournald2+0xbd/0x270 [jbd2] > > So if we don't have block device open with O_EXCL already, claim the > block device while we truncate buffer cache. This makes sure any > exclusive block device user (such as filesystem) cannot operate on the > device while we are discarding buffer cache. > > Reported-by: Ye Bin <ye...@hu...> > Signed-off-by: Jan Kara <ja...@su...> > Reviewed-by: Christoph Hellwig <hc...@ls...> > [axboe: fix !CONFIG_BLOCK error in truncate_bdev_range()] > Signed-off-by: Jens Axboe <ax...@ke...> > > As far as I can tell the commit is intended to stop you from doing > blkdiscard on a block device which is in use by a (kernel) filesystem, > which sounds like a good idea. Breakage of FUSE devices that use > block devices is possibly an unintentional side-effect. So how is fstrim(8) supposed to be used ? Currently it requires a mounted file system as its last argument. Technically ntfs-3g can close the device (without unmounting), reopen it without O_EXCL for trimming, and reopen again with O_EXCL, but this sounds like a very bad way of doing. How does the ext4 driver allow allow the discarding to take place ? Jean-Pierre > > Although reverting the commit fixes it, I've no idea how to fix it > properly. > > Rich. > > (BTW I'm unable to subscribe to ntfs-3g-devel ...) > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-19 11:04:39
|
Kevin Peng wrote on 1/19/21 8:57 AM: > On Mon, Jan 18, 2021 at 6:45 PM Kevin Peng <kkp...@gm...> wrote: >> >> On Fri, Jan 15, 2021 at 7:57 AM Jean-Pierre André >> <jea...@wa...> wrote: >>>> So I've tried creating some links and special files with the >>>> special_files=wsl mount option, and reading those in WSL. WSL was >>>> successfully able to read links I created to "dir", "file", "文件", and >>>> "\x17\x15\ufffe\uffff". The fifos, block and char special devices look >>>> like empty regular files to WSL though (with no permissions, and owned >>>> by whichever user and group was specified in the DrvFS mount options). >>> >>> Fine, so the symlink target is utf8 encoded. >>> >>> I have uploaded a new test version on >>> https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-3.tgz >>> with fifo and char and block device according to your example. >>> >>> However ownership and permissions are not inserted into the EA. >>> This may be a problem as permissions are merged with the type >>> to form the $LXMOD. WSL might require the $LXMOD to be present >>> and match the type defined by the reparse tag. >>> >>> I hope ownership and permissions are not required, and this >>> would be consistent with WSL being able to process Windows >>> files without polluting them. >>> >>> If the fifo with no $LXMOD is not recognized by WSL, would you >>> please add it to an existing fifo as shown below (long lines >>> could be split by the mailer) >>> >>> (adding $LXMOD only) >>> # mknod wsl/fifo-1 p >>> # setfattr -h -v 0x1400000000060400244c584d4f4400a411000000 -n >>> system.ntfs_ea wsl/fifo-1 >>> >>> (adding $LXUID, $LXGID and $LXMOD) >>> # mknod wsl/fifo-2 p >>> # setfattr -h -v >>> 0x1400000000060400244c5855494400e8030000001400000000060400244c5847494400e8030000001400000000060400244c584d4f4400a411000000 >>> -n system.ntfs_ea wsl/fifo-2 >> >> So your most recent version of ntfs-3g indeed interprets WSL-generated >> block, char, fifos, and symlinks correctly. >> >> The very interesting behavior is when WSL tries to interpret the >> ntfs-3g generated block, char and fifos: >> - getdents64() correctly identifies those files as a block, char and >> fifo respectively. >> - However, statx() thinks the block and char files are regular files, >> and returns ENOENT when one tries to stat() the fifo. >> >> Adding $LXMOD to the fifo, however, resulted in correct behavior: in >> my case, the ls -l output for that fifo (in my case) is prw-r--r--. >> Adding $LXUID and $LXGID was not required. >> >> Best, >> Kevin > > Addendum: Similarly, if I add an $LXMOD to the block and char devices > by using the commands > > setfattr -h -v 0x1400000000060400244c584d4f4400a4610000001800000000060800244c5844455600340200006705000000 > -n system.ntfs_ea block > > and > > setfattr -h -v 0x1400000000060400244c584d4f4400a4210000001800000000060800244c5844455600230100005604000000 > -n system.ntfs_ea char > > then WSL correctly identifies them as block and char devices > respectively, with permissions 644. Fine and thanks for testing. So I have added a $LXMOD for special files except symlinks. It contains a redundant mode, with the permissions hard coded as 0644. After cleaning the code and inserting the $LXMOD, I have uploaded the updated tarball to : https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-4.tgz Unless something undesirable is found, this could be the next version ntfs-3g_ntfsprogs-2017.3.23AR.6. Jean-Pierre |
|
From: Kevin P. <kkp...@gm...> - 2021-01-19 07:57:50
|
On Mon, Jan 18, 2021 at 6:45 PM Kevin Peng <kkp...@gm...> wrote: > > On Fri, Jan 15, 2021 at 7:57 AM Jean-Pierre André > <jea...@wa...> wrote: > > > So I've tried creating some links and special files with the > > > special_files=wsl mount option, and reading those in WSL. WSL was > > > successfully able to read links I created to "dir", "file", "文件", and > > > "\x17\x15\ufffe\uffff". The fifos, block and char special devices look > > > like empty regular files to WSL though (with no permissions, and owned > > > by whichever user and group was specified in the DrvFS mount options). > > > > Fine, so the symlink target is utf8 encoded. > > > > I have uploaded a new test version on > > https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-3.tgz > > with fifo and char and block device according to your example. > > > > However ownership and permissions are not inserted into the EA. > > This may be a problem as permissions are merged with the type > > to form the $LXMOD. WSL might require the $LXMOD to be present > > and match the type defined by the reparse tag. > > > > I hope ownership and permissions are not required, and this > > would be consistent with WSL being able to process Windows > > files without polluting them. > > > > If the fifo with no $LXMOD is not recognized by WSL, would you > > please add it to an existing fifo as shown below (long lines > > could be split by the mailer) > > > > (adding $LXMOD only) > > # mknod wsl/fifo-1 p > > # setfattr -h -v 0x1400000000060400244c584d4f4400a411000000 -n > > system.ntfs_ea wsl/fifo-1 > > > > (adding $LXUID, $LXGID and $LXMOD) > > # mknod wsl/fifo-2 p > > # setfattr -h -v > > 0x1400000000060400244c5855494400e8030000001400000000060400244c5847494400e8030000001400000000060400244c584d4f4400a411000000 > > -n system.ntfs_ea wsl/fifo-2 > > So your most recent version of ntfs-3g indeed interprets WSL-generated > block, char, fifos, and symlinks correctly. > > The very interesting behavior is when WSL tries to interpret the > ntfs-3g generated block, char and fifos: > - getdents64() correctly identifies those files as a block, char and > fifo respectively. > - However, statx() thinks the block and char files are regular files, > and returns ENOENT when one tries to stat() the fifo. > > Adding $LXMOD to the fifo, however, resulted in correct behavior: in > my case, the ls -l output for that fifo (in my case) is prw-r--r--. > Adding $LXUID and $LXGID was not required. > > Best, > Kevin Addendum: Similarly, if I add an $LXMOD to the block and char devices by using the commands setfattr -h -v 0x1400000000060400244c584d4f4400a4610000001800000000060800244c5844455600340200006705000000 -n system.ntfs_ea block and setfattr -h -v 0x1400000000060400244c584d4f4400a4210000001800000000060800244c5844455600230100005604000000 -n system.ntfs_ea char then WSL correctly identifies them as block and char devices respectively, with permissions 644. |
|
From: Kevin P. <kkp...@gm...> - 2021-01-19 02:45:49
|
On Fri, Jan 15, 2021 at 7:57 AM Jean-Pierre André <jea...@wa...> wrote: > > So I've tried creating some links and special files with the > > special_files=wsl mount option, and reading those in WSL. WSL was > > successfully able to read links I created to "dir", "file", "文件", and > > "\x17\x15\ufffe\uffff". The fifos, block and char special devices look > > like empty regular files to WSL though (with no permissions, and owned > > by whichever user and group was specified in the DrvFS mount options). > > Fine, so the symlink target is utf8 encoded. > > I have uploaded a new test version on > https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-3.tgz > with fifo and char and block device according to your example. > > However ownership and permissions are not inserted into the EA. > This may be a problem as permissions are merged with the type > to form the $LXMOD. WSL might require the $LXMOD to be present > and match the type defined by the reparse tag. > > I hope ownership and permissions are not required, and this > would be consistent with WSL being able to process Windows > files without polluting them. > > If the fifo with no $LXMOD is not recognized by WSL, would you > please add it to an existing fifo as shown below (long lines > could be split by the mailer) > > (adding $LXMOD only) > # mknod wsl/fifo-1 p > # setfattr -h -v 0x1400000000060400244c584d4f4400a411000000 -n > system.ntfs_ea wsl/fifo-1 > > (adding $LXUID, $LXGID and $LXMOD) > # mknod wsl/fifo-2 p > # setfattr -h -v > 0x1400000000060400244c5855494400e8030000001400000000060400244c5847494400e8030000001400000000060400244c584d4f4400a411000000 > -n system.ntfs_ea wsl/fifo-2 So your most recent version of ntfs-3g indeed interprets WSL-generated block, char, fifos, and symlinks correctly. The very interesting behavior is when WSL tries to interpret the ntfs-3g generated block, char and fifos: - getdents64() correctly identifies those files as a block, char and fifo respectively. - However, statx() thinks the block and char files are regular files, and returns ENOENT when one tries to stat() the fifo. Adding $LXMOD to the fifo, however, resulted in correct behavior: in my case, the ls -l output for that fifo (in my case) is prw-r--r--. Adding $LXUID and $LXGID was not required. Best, Kevin |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-15 15:57:21
|
Hi Kevin Kevin Peng wrote on 1/14/21 9:03 AM: >>>> I have uploaded to >>>> https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz >>>> a test version of ntfs-3g with support for WSL-type symlinks. >>>> This variant is enabled by using the mount option : >>>> special_files=wsl >>>> Both the Interix symlinks and the WSL ones are recognized >>>> irrespective of the option being used. The option only acts >>>> on new symlinks being created. >>>> >>>> Please test it, and report. >>> >>> Thanks! I'll test it and report back. >>> [...] > > So I've tried creating some links and special files with the > special_files=wsl mount option, and reading those in WSL. WSL was > successfully able to read links I created to "dir", "file", "文件", and > "\x17\x15\ufffe\uffff". The fifos, block and char special devices look > like empty regular files to WSL though (with no permissions, and owned > by whichever user and group was specified in the DrvFS mount options). Fine, so the symlink target is utf8 encoded. I have uploaded a new test version on https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-3.tgz with fifo and char and block device according to your example. However ownership and permissions are not inserted into the EA. This may be a problem as permissions are merged with the type to form the $LXMOD. WSL might require the $LXMOD to be present and match the type defined by the reparse tag. I hope ownership and permissions are not required, and this would be consistent with WSL being able to process Windows files without polluting them. If the fifo with no $LXMOD is not recognized by WSL, would you please add it to an existing fifo as shown below (long lines could be split by the mailer) (adding $LXMOD only) # mknod wsl/fifo-1 p # setfattr -h -v 0x1400000000060400244c584d4f4400a411000000 -n system.ntfs_ea wsl/fifo-1 (adding $LXUID, $LXGID and $LXMOD) # mknod wsl/fifo-2 p # setfattr -h -v 0x1400000000060400244c5855494400e8030000001400000000060400244c5847494400e8030000001400000000060400244c584d4f4400a411000000 -n system.ntfs_ea wsl/fifo-2 Jean-Pierre > >> >>> >>> For completeness, I post the ntfsinfo of fifo, block, and char below: >>> $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F fifo links.img >> >> FYI ntfsinfo shows the details of EA's in verbose mode >> (with option -v). > > Thanks, I'll try that next time. > > Best, > Kevin > > > _______________________________________________ > ntfs-3g-devel mailing list > ntf...@li... > https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel > |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-14 13:49:45
|
Didier Spaier wrote on 1/14/21 2:02 AM: > Hi Jean-Pierre and All, > > I have asked a similar question, last post in the thread: > https://sourceforge.net/p/ntfs-3g/mailman/message/37119780/ > > For now in the new 'auto' mode of the Slint installer I just advise > users to > shrink the last NTFS partition from Window to make from for Slint before > installing it, as written here: > http://slackware.uk/slint/x86_64/slint-14.2.1/doc/New_Installer/Doc_in_the_installer/FreeSpace > > > I did that because I really don't want that a user can't boot Windows > any more > after having installed Slint alongside Windows. > > However, and taking in account the extra space needed in case of a > Windows > update that you mentioned, is there a way I can compute a "certainly > safe" > minimum size of the NTFS file system? I usually configure a 64GB partition for Windows 10 and I put all user data into another partition. Windows 10 uses about half of it, but I have observed it may need 10GB to 20GB more space when updating. I would recommend leaving 32GB free space to Windows. When resizing a fragmented partition, relocated data has to be split into the available space in the target space. This implies more fragmentation and more metadata to describe the fragmented files. So I would recommend not resizing into less than the currently used space + 10%, and you probably need much more during Windows updates. Note : ntfsresize with option --info returns the currently used space. A safety margin over this has to be included in the target size. Jean-Pierre > > Best regards, > Didier |
|
From: Kevin P. <kkp...@gm...> - 2021-01-14 08:05:13
|
> >> I have uploaded to > >> https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz > >> a test version of ntfs-3g with support for WSL-type symlinks. > >> This variant is enabled by using the mount option : > >> special_files=wsl > >> Both the Interix symlinks and the WSL ones are recognized > >> irrespective of the option being used. The option only acts > >> on new symlinks being created. > >> > >> Please test it, and report. > > > > Thanks! I'll test it and report back. > > > >> > >> The sockets, fifos, character and block devices are also > >> implemented the same way.... but I have no valid example > >> of how WSL implements them, so this is probably plain wrong. > >> > >> Would you please use WSL to create some of them and post > >> their ntfsinfo description : > >> > >> mknod path/fifo p > >> mknod path/chr c 0x123 0x456 > >> mknod path/blk b 0x234 0x567 > > > > WSL encodes fifos and block/character device files using NTFS extended > > attributes. (For that matter, any file can have such extended > > attributes attached to it, in order to encode properties such as its > > permissions within WSL.) You can find more details about these here: > > [0] > > > > I've created a test disk image here: https://ocf.io/kpengboy/links.img > > It contains several files: > > Great job, thanks. > > > - symlink: a symlink with the contents "abcéж我☃" > > - symlink-with-metadata: same as above, but with the WSL metadata > > attached in the NTFS extended attributes > > - fifo > > - block, char: with major and minor numbers as requested in your email > > - stream-socket-maybe: I tried to bind a Unix socket to a file and > > this is the result. I may or may not have done it correctly. The result may > > or may not be meaningful. > > IMHO having compatible socket is only needed if you want to > communicate between WSL and Linux as a guest on Windows.... > > > > > [0] https://docs.microsoft.com/en-us/windows/wsl/file-permissions > > So for devices, the major and minor number are inserted in an > EA, with ownership and permissions. Then an important question > is whether ownership and permissions are required for the device > number to be taken into account (and more generally whether > they are required for special files to be recognized by wsl). > > At this stage I am not to provide support for wsl-type ownership > and permissions. > > What does wsl think of a fifo created by the test version of > ntfs-3g ? is it at least shown as a fifo (probably owned by > root and no permissions) ? It is also missing the flag 0x40000, > which could be a requirement. So I've tried creating some links and special files with the special_files=wsl mount option, and reading those in WSL. WSL was successfully able to read links I created to "dir", "file", "文件", and "\x17\x15\ufffe\uffff". The fifos, block and char special devices look like empty regular files to WSL though (with no permissions, and owned by whichever user and group was specified in the DrvFS mount options). > > > > > For completeness, I post the ntfsinfo of fifo, block, and char below: > > $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F fifo links.img > > FYI ntfsinfo shows the details of EA's in verbose mode > (with option -v). Thanks, I'll try that next time. Best, Kevin |
|
From: Didier S. <di...@sl...> - 2021-01-14 01:21:05
|
Hi Jean-Pierre and All, I have asked a similar question, last post in the thread: https://sourceforge.net/p/ntfs-3g/mailman/message/37119780/ For now in the new 'auto' mode of the Slint installer I just advise users to shrink the last NTFS partition from Window to make from for Slint before installing it, as written here: http://slackware.uk/slint/x86_64/slint-14.2.1/doc/New_Installer/Doc_in_the_installer/FreeSpace I did that because I really don't want that a user can't boot Windows any more after having installed Slint alongside Windows. However, and taking in account the extra space needed in case of a Windows update that you mentioned, is there a way I can compute a "certainly safe" minimum size of the NTFS file system? Best regards, Didier |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-13 18:12:02
|
Kevin Peng wrote on 1/13/21 5:00 PM: > Hi Jean-Pierre, > >>>> getfattr simply fails with EIO when I try to issue the commands you >>>> requested. I did run ntfsinfo on the symlinks though. I have included >>> >>> That is strange. Maybe you did not use the -h option of fgetattr ? > It seems the ntfs-3g packaged by Debian was not functioning properly. > With the tarball you gave me it works properly. > >> >> I have uploaded to >> https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz >> a test version of ntfs-3g with support for WSL-type symlinks. >> This variant is enabled by using the mount option : >> special_files=wsl >> Both the Interix symlinks and the WSL ones are recognized >> irrespective of the option being used. The option only acts >> on new symlinks being created. >> >> Please test it, and report. > > Thanks! I'll test it and report back. > >> >> The sockets, fifos, character and block devices are also >> implemented the same way.... but I have no valid example >> of how WSL implements them, so this is probably plain wrong. >> >> Would you please use WSL to create some of them and post >> their ntfsinfo description : >> >> mknod path/fifo p >> mknod path/chr c 0x123 0x456 >> mknod path/blk b 0x234 0x567 > > WSL encodes fifos and block/character device files using NTFS extended > attributes. (For that matter, any file can have such extended > attributes attached to it, in order to encode properties such as its > permissions within WSL.) You can find more details about these here: > [0] > > I've created a test disk image here: https://ocf.io/kpengboy/links.img > It contains several files: Great job, thanks. > - symlink: a symlink with the contents "abcéж我☃" > - symlink-with-metadata: same as above, but with the WSL metadata > attached in the NTFS extended attributes > - fifo > - block, char: with major and minor numbers as requested in your email > - stream-socket-maybe: I tried to bind a Unix socket to a file and > this is the result. I may or may not have done it correctly. The result may > or may not be meaningful. IMHO having compatible socket is only needed if you want to communicate between WSL and Linux as a guest on Windows.... > > [0] https://docs.microsoft.com/en-us/windows/wsl/file-permissions So for devices, the major and minor number are inserted in an EA, with ownership and permissions. Then an important question is whether ownership and permissions are required for the device number to be taken into account (and more generally whether they are required for special files to be recognized by wsl). At this stage I am not to provide support for wsl-type ownership and permissions. What does wsl think of a fifo created by the test version of ntfs-3g ? is it at least shown as a fifo (probably owned by root and no permissions) ? It is also missing the flag 0x40000, which could be a requirement. > > For completeness, I post the ntfsinfo of fifo, block, and char below: > $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F fifo links.img FYI ntfsinfo shows the details of EA's in verbose mode (with option -v). [...] Jean-Pierre |
|
From: Kevin P. <kkp...@gm...> - 2021-01-13 16:02:03
|
Hi Jean-Pierre, > >> getfattr simply fails with EIO when I try to issue the commands you > >> requested. I did run ntfsinfo on the symlinks though. I have included > > > > That is strange. Maybe you did not use the -h option of fgetattr ? It seems the ntfs-3g packaged by Debian was not functioning properly. With the tarball you gave me it works properly. > > I have uploaded to > https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz > a test version of ntfs-3g with support for WSL-type symlinks. > This variant is enabled by using the mount option : > special_files=wsl > Both the Interix symlinks and the WSL ones are recognized > irrespective of the option being used. The option only acts > on new symlinks being created. > > Please test it, and report. Thanks! I'll test it and report back. > > The sockets, fifos, character and block devices are also > implemented the same way.... but I have no valid example > of how WSL implements them, so this is probably plain wrong. > > Would you please use WSL to create some of them and post > their ntfsinfo description : > > mknod path/fifo p > mknod path/chr c 0x123 0x456 > mknod path/blk b 0x234 0x567 WSL encodes fifos and block/character device files using NTFS extended attributes. (For that matter, any file can have such extended attributes attached to it, in order to encode properties such as its permissions within WSL.) You can find more details about these here: [0] I've created a test disk image here: https://ocf.io/kpengboy/links.img It contains several files: - symlink: a symlink with the contents "abcéж我☃" - symlink-with-metadata: same as above, but with the WSL metadata attached in the NTFS extended attributes - fifo - block, char: with major and minor numbers as requested in your email - stream-socket-maybe: I tried to bind a Unix socket to a file and this is the result. I may or may not have done it correctly. The result may or may not be meaningful. [0] https://docs.microsoft.com/en-us/windows/wsl/file-permissions For completeness, I post the ntfsinfo of fifo, block, and char below: $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F fifo links.img Dumping Inode 35 (0x23) Upd. Seq. Array Off.: 48 (0x30) Upd. Seq. Array Count: 3 (0x3) Upd. Seq. Number: 3 (0x3) LogFile Seq. Number: 0x102caa MFT Record Seq. Numb.: 1 (0x1) Number of Hard Links: 1 (0x1) Attribute Offset: 56 (0x38) MFT Record Flags: IN_USE Bytes Used: 440 (0x1b8) bytes Bytes Allocated: 1024 (0x400) bytes Next Attribute Instance: 6 (0x6) MFT Padding: 00 00 Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 0 (0x0) Data size: 72 (0x48) Resident flags: 0x00 File Creation Time: Sun Jan 10 10:34:55 2021 UTC File Altered Time: Sun Jan 10 10:34:55 2021 UTC MFT Changed Time: Sun Jan 10 10:34:55 2021 UTC Last Accessed Time: Sun Jan 10 10:34:55 2021 UTC File attributes: ARCHIVE REPARSE_POINT UNKNOWN: 0x00040000 (0x00040420) Maximum versions: 0 Version number: 0 Class ID: 0 User ID: 0 (0x0) Security ID: 260 (0x104) Quota charged: 0 (0x0) Update Sequence Number: 0 (0x0) Dumping attribute $FILE_NAME (0x30) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 2 (0x2) Data size: 74 (0x4a) Resident flags: 0x01 Parent directory: 5 (0x5) File Creation Time: Sun Jan 10 10:34:55 2021 UTC File Altered Time: Sun Jan 10 10:34:55 2021 UTC MFT Changed Time: Sun Jan 10 10:34:55 2021 UTC Last Accessed Time: Sun Jan 10 10:34:55 2021 UTC Allocated Size: 0 (0x0) Data Size: 0 (0x0) Filename Length: 4 (0x4) File attributes: ARCHIVE (0x00000020) Namespace: POSIX Filename: 'fifo' Dumping attribute $DATA (0x80) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 1 (0x1) Data size: 0 (0x0) Resident flags: 0x00 Dumping attribute $REPARSE_POINT (0xc0) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 3 (0x3) Data size: 8 (0x8) Resident flags: 0x00 Reparse tag: 0x80000024 (Linux fifo) Data length: 0 (0x0) Data: (NONE) Dumping attribute $EA_INFORMATION (0xd0) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 4 (0x4) Data size: 8 (0x8) Resident flags: 0x00 Packed EA length: 45 (0x2d) NEED_EA count: 0 (0x0) Unpacked EA length: 60 (0x3c) Dumping attribute $EA (0xe0) from mft record 35 (0x23) Resident: Yes Attribute flags: 0x0000 Attribute instance: 5 (0x5) Data size: 60 (0x3c) Resident flags: 0x00 End of inode reached $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F block links.img Dumping Inode 36 (0x24) Upd. Seq. Array Off.: 48 (0x30) Upd. Seq. Array Count: 3 (0x3) Upd. Seq. Number: 3 (0x3) LogFile Seq. Number: 0x181045 MFT Record Seq. Numb.: 2 (0x2) Number of Hard Links: 1 (0x1) Attribute Offset: 56 (0x38) MFT Record Flags: IN_USE Bytes Used: 464 (0x1d0) bytes Bytes Allocated: 1024 (0x400) bytes Next Attribute Instance: 6 (0x6) MFT Padding: 00 00 Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 0 (0x0) Data size: 72 (0x48) Resident flags: 0x00 File Creation Time: Wed Jan 13 08:40:56 2021 UTC File Altered Time: Wed Jan 13 08:40:56 2021 UTC MFT Changed Time: Wed Jan 13 08:40:56 2021 UTC Last Accessed Time: Wed Jan 13 08:40:56 2021 UTC File attributes: ARCHIVE REPARSE_POINT UNKNOWN: 0x00040000 (0x00040420) Maximum versions: 0 Version number: 0 Class ID: 0 User ID: 0 (0x0) Security ID: 260 (0x104) Quota charged: 0 (0x0) Update Sequence Number: 0 (0x0) Dumping attribute $FILE_NAME (0x30) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 2 (0x2) Data size: 76 (0x4c) Resident flags: 0x01 Parent directory: 5 (0x5) File Creation Time: Wed Jan 13 08:40:56 2021 UTC File Altered Time: Wed Jan 13 08:40:56 2021 UTC MFT Changed Time: Wed Jan 13 08:40:56 2021 UTC Last Accessed Time: Wed Jan 13 08:40:56 2021 UTC Allocated Size: 0 (0x0) Data Size: 0 (0x0) Filename Length: 5 (0x5) File attributes: ARCHIVE (0x00000020) Namespace: POSIX Filename: 'block' Dumping attribute $DATA (0x80) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 1 (0x1) Data size: 0 (0x0) Resident flags: 0x00 Dumping attribute $REPARSE_POINT (0xc0) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 3 (0x3) Data size: 8 (0x8) Resident flags: 0x00 Reparse tag: 0x80000026 (Linux block device) Data length: 0 (0x0) Data: (NONE) Dumping attribute $EA_INFORMATION (0xd0) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 4 (0x4) Data size: 8 (0x8) Resident flags: 0x00 Packed EA length: 64 (0x40) NEED_EA count: 0 (0x0) Unpacked EA length: 84 (0x54) Dumping attribute $EA (0xe0) from mft record 36 (0x24) Resident: Yes Attribute flags: 0x0000 Attribute instance: 5 (0x5) Data size: 84 (0x54) Resident flags: 0x00 End of inode reached $ src/ntfs-3g_ntfsprogs-2017.3.23AB.6/ntfsprogs/ntfsinfo -F char links.img Dumping Inode 37 (0x25) Upd. Seq. Array Off.: 48 (0x30) Upd. Seq. Array Count: 3 (0x3) Upd. Seq. Number: 2 (0x2) LogFile Seq. Number: 0x181190 MFT Record Seq. Numb.: 2 (0x2) Number of Hard Links: 1 (0x1) Attribute Offset: 56 (0x38) MFT Record Flags: IN_USE Bytes Used: 464 (0x1d0) bytes Bytes Allocated: 1024 (0x400) bytes Next Attribute Instance: 6 (0x6) MFT Padding: 00 00 Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 0 (0x0) Data size: 72 (0x48) Resident flags: 0x00 File Creation Time: Wed Jan 13 08:41:05 2021 UTC File Altered Time: Wed Jan 13 08:41:05 2021 UTC MFT Changed Time: Wed Jan 13 08:41:05 2021 UTC Last Accessed Time: Wed Jan 13 08:41:05 2021 UTC File attributes: ARCHIVE REPARSE_POINT UNKNOWN: 0x00040000 (0x00040420) Maximum versions: 0 Version number: 0 Class ID: 0 User ID: 0 (0x0) Security ID: 260 (0x104) Quota charged: 0 (0x0) Update Sequence Number: 0 (0x0) Dumping attribute $FILE_NAME (0x30) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 2 (0x2) Data size: 74 (0x4a) Resident flags: 0x01 Parent directory: 5 (0x5) File Creation Time: Wed Jan 13 08:41:05 2021 UTC File Altered Time: Wed Jan 13 08:41:05 2021 UTC MFT Changed Time: Wed Jan 13 08:41:05 2021 UTC Last Accessed Time: Wed Jan 13 08:41:05 2021 UTC Allocated Size: 0 (0x0) Data Size: 0 (0x0) Filename Length: 4 (0x4) File attributes: ARCHIVE (0x00000020) Namespace: POSIX Filename: 'char' Dumping attribute $DATA (0x80) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 1 (0x1) Data size: 0 (0x0) Resident flags: 0x00 Dumping attribute $REPARSE_POINT (0xc0) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 3 (0x3) Data size: 8 (0x8) Resident flags: 0x00 Reparse tag: 0x80000025 (Linux character device) Data length: 0 (0x0) Data: (NONE) Dumping attribute $EA_INFORMATION (0xd0) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 4 (0x4) Data size: 8 (0x8) Resident flags: 0x00 Packed EA length: 64 (0x40) NEED_EA count: 0 (0x0) Unpacked EA length: 84 (0x54) Dumping attribute $EA (0xe0) from mft record 37 (0x25) Resident: Yes Attribute flags: 0x0000 Attribute instance: 5 (0x5) Data size: 84 (0x54) Resident flags: 0x00 End of inode reached Best, Kevin |
|
From: Douglas P. <do...@bo...> - 2021-01-12 20:45:43
|
On Tue, Jan 12, 2021 at 04:59:51PM +0100, Jean-Pierre André wrote:
> Not exactly : what the documentation says is that reparse points
> and EA's are incompatible. They are both supposed to be returned
> in dwReserved0 by FindFirstFile()... However Microsoft does not
> respect this anymore, as you can see in your post of ntfsinfo
> for 'AppxManifest.xml'
Ah, that is the reason why both are not supposed to be present.
I guess the newest documentation says it is only for the reparse data,
now, but of course it could still be set for EAs as an undocumented
feature.
I also saw some people complaining that chkdsk in Windows 7 would flag
this as an error, so people are not able to dual boot Windows 7 and
Windows 10 on the same system cleanly. (Windows 7 chkdsk will break
these WofCompressed files).
Anyway, I commented out the exclusions related to not allowing ntfs_ea
and ntfs_reparse_data on the same file, and everything seems to be
'okay'.
> Anyway, the issue is that named streams are used both for
> extended attributes and for the WOF compressed data. Historically
> EA's were designed for OS/2 extended attributes, and their
> limitations were dissuasive for representing Linux extended
> attributes, so named streams are used instead. This was consistent
> with Microsoft Office using named streams for a similar purpose.
>
> The issue is actually telling which named streams are extended
> attributes and which ones are not. And having a generic way to
> do so to avoid having to maintain a sort of black list.
Okay, that makes sense. So normal POSIX xattrs cannot be used with
streams_interface=windows -- and for WofCompressed you have to use this
(if you want to access the data without going through a plugin).
> It would be useful you explain your use case. The WofCompressed files
> are Windows system files which you cannot backup and restore as if
> they were plain files. A system partition is best copied as a whole.
>
> You are unlikely to have user files being WofCompressed.
>
> Note : when using "streams_interface=windows" you should not use
> xattr, you can read and write the raw attribute by appending a
> colon and the name of the stream to the file name (for instance :
> AppxManifest.xml:WofCompressedData), and you have a big limit on
> the stream size.
Why is there a limit? I assumed that it was stored like any file data
(due to it being a $DATA node).
So my use case is quite particular and not likely to be common.
I have a small SSD that I am using for the main system drive, and I want
to fit the C: drive on it. I don't use Windows much, so I don't want to
dedicate much space to it. So, what I usually did was move all the
Program Files to another drive, and use a reparse point to redirect it.
This usually works fine, except when it comes do updates, due to the use
of hard links into WinSxS.
So, I wanted to try to do an analysis to do an intelligent move of this
directory -- basically -- anywhere where there are things that are
hardlinked with things in WinSxS, to leave on the SSD (since it won't
save space moving them anyway), and other things move to the drive. I'm
hoping by having reparse points from the second drive back to the C:
drive, it will allow hardlinks to continue to work where they are used,
so updates should also work.
To make that easier, I added an xattr (internal, under system.ntfs_*)
that lists all the possible aliases to the same file as seen by the
filesystem (since that is pretty cheap to do with NTFS it seems --
easier than scanning the whole filesystem and looking for duplicate
inodes)
Finally, to do this completely, I would need to copy WofCompressed files
-- which seems to work fine if I remove the reparse data, copy the file
(making sure to make the main stream sparse and empty and include the
WofCompressed stream), and then apply the reparse data back to both
files. I am not using any plugins. I had to use the
streams_interface=windows to handle cases where the WofCompressed stream
is too large to pass through the xattr interface. It works well, but
seems to make it impossible to make the drive symlinks in the .NTFS-3G
directory to make reparse symlinks work. It might be worth removing the
':' from those anyway, because Windows chkdsk complains about them
anyway.
The idea also is to be able to 'unwind' this if I ever decide to get a
bigger drive.
I did run into one issue playing with these reparse points lacking
plugins where I would sometimes get EIO on any access to the file, where
an initial stat() done by fuse fails. But I was able to fix that with
this small change:
diff --git a/src/ntfs-3g.c b/src/ntfs-3g.c
index 2eb197a8..a15c623e 100644
--- a/src/ntfs-3g.c
+++ b/src/ntfs-3g.c
@@ -147,7 +147,7 @@
#define CALL_REPARSE_PLUGIN(ni, op_name, ...) \
(reparse = (REPARSE_POINT*)NULL, \
ops = select_reparse_plugin(ctx, ni, &reparse), \
- (!ops ? -errno \
+ (!ops ? (errno ? -errno : -EOPNOTSUPP) \
: (ops->op_name ? \
ops->op_name(ni, reparse, __VA_ARGS__) \
: -EOPNOTSUPP))), \
(The symptom also is that ls -l would not show the files as symlinks to
'unsupported reparse point'.)
This is basically because when we use this from stat, if
select_reparse_plugin doesn't set errno (which I guess it doesn't
always), it would treat it like the call to have the plugin fill the
stat structure succeeded, so it wouldn't be filled with the information
from the dummy symlink, and fuse would mark this as an error.
> > Here is an example of some files I found. They all seem to have the
> > 0x40000 attribute. Sometimes the EA points to a package name.
>
> This is interesting. Maybe 0x40000 (whose purpose I do not know)
> can be used to tell whether a file is a Windows system file which
> is not eligible for Linux extended attributes.
I found them here:
https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants
It says it means FILE_ATTRIBUTE_RECALL_ON_OPEN which seems to mean the
data might need to be fetched from elsewhere? I don't know what that
means at all. Maybe they have repurposed the attribute that is normally
not used directly on the filesystem for some other meaning. Or maybe it
is just a signal that the file's data is provided by some function that
processes the special reparse point, and the main stream is really
empty. I didn't check if it was set on all WofCompressed files.
> ntfs-3g does not use the EA's at all. Microsoft probably use them
> in the update process, so better not to interfere. Consequently they
> are probably not eligible for extended attributes either (but checking
> for EA presence would be heavy for this purpose).
Right now, I'm trying to copy them with the system.ntfs_ea xattr, which
seems to work, but I didn't check if it is correct.
Thanks for the information and clarifications.
--
Douglas Paul
|
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-12 16:36:57
|
Hi Kevin, Jean-Pierre André wrote on 1/9/21 9:29 PM: > Hi, > > Kevin Peng wrote on 1/9/21 5:00 PM: >> Hello Jean-Pierre, >> >> I created the following symlinks in WSL in a test directory, along >> with a file named "foo" and a directory named "bar": >> relative-symlink-to-file -> foo >> relative-symlink-to-dir -> bar >> relative-symlink-to-nonexistent -> nonexistent >> absolute-symlink-to-file -> /mnt/d/testsymlink/foo >> absolute-symlink-to-dir -> /mnt/d/testsymlink/bar >> absolute-symlink-to-nonexistent -> /nonexistent >> >> (Note that WSL sometimes creates native Windows symlinks and sometimes >> creates its own WSL symlinks; I took care to ensure that all of the >> symlinks I created were of the latter type.) > > Great ! > >> getfattr simply fails with EIO when I try to issue the commands you >> requested. I did run ntfsinfo on the symlinks though. I have included > > That is strange. Maybe you did not use the -h option of fgetattr ? > > Anyway, as you posted the full ntfsinfo, I now have the full > picture. I see that symlinks to directories are based on a > regular file pattern, which is a major difference from > Windows symlinks. > >> the full output at the bottom of this email. The principal finding is >> that the reparse point data is the bytes 02000000 followed by the > > This field must have some meaning... > >> contents of the symlink. Mirroring POSIX semantics, it appears that >> the type or existence of the target has no effect on the format of the >> reparse point data. I'll try this again with a non-ASCII symlink >> target to verify which encoding it uses. >> >> $ sudo ntfsinfo -F /testsymlink/relative-symlink-to-file /dev/nvme0n1p7 >> > [...] > > I tried such a relative symlink on Windows 10 and I was > disappointed to see it was not supported and it appeared > as a regular file. There is no improvement over the Interix > implementation. > > I saw that reparse tags have been defined for all special > files, so better also implement them in the same step. > Can you also post the ntfsinfo output for a fifo, a char > device and a block device ? For sockets I will probably > have to make some guess work, but having the same layout > as WSL is probably not essential. > > Jean-Pierre I have uploaded to https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz a test version of ntfs-3g with support for WSL-type symlinks. This variant is enabled by using the mount option : special_files=wsl Both the Interix symlinks and the WSL ones are recognized irrespective of the option being used. The option only acts on new symlinks being created. Please test it, and report. The sockets, fifos, character and block devices are also implemented the same way.... but I have no valid example of how WSL implements them, so this is probably plain wrong. Would you please use WSL to create some of them and post their ntfsinfo description : mknod path/fifo p mknod path/chr c 0x123 0x456 mknod path/blk b 0x234 0x567 Thanks, Jean-Pierre |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-12 16:00:23
|
Douglas Paul wrote on 1/11/21 3:21 PM: > Hello, > > I noticed in the documentation (and confirmed with some random pages of > MS documentation) that reparse points are not supposed to be supported > when there are extended attributes. Not exactly : what the documentation says is that reparse points and EA's are incompatible. They are both supposed to be returned in dwReserved0 by FindFirstFile()... However Microsoft does not respect this anymore, as you can see in your post of ntfsinfo for 'AppxManifest.xml' Anyway, the issue is that named streams are used both for extended attributes and for the WOF compressed data. Historically EA's were designed for OS/2 extended attributes, and their limitations were dissuasive for representing Linux extended attributes, so named streams are used instead. This was consistent with Microsoft Office using named streams for a similar purpose. > > This doesn't seem to be true anymore, at least for files that use > 'WofCompressedData' and also come from a package. > > Should there be any danger to remove the check for EAs when setting > reparse data, or maybe it should only be done for 'small' reparse tags? The issue is actually telling which named streams are extended attributes and which ones are not. And having a generic way to do so to avoid having to maintain a sort of black list. > I noticed this when trying to manipulate files with reparse data to > properly copy them. What I was doing was removing the reparse data, so > symlinks could be copied correctly with the correct type (file or > directory), and the reapply it after. For WofCompressed files, I planned > to copy the data using the "streams_interface=windows" option because > sometimes the data is too large to pass with xattr. However, this failed > because after the reparse attribute was removed, it could not be put > back. It would be useful you explain your use case. The WofCompressed files are Windows system files which you cannot backup and restore as if they were plain files. A system partition is best copied as a whole. You are unlikely to have user files being WofCompressed. Note : when using "streams_interface=windows" you should not use xattr, you can read and write the raw attribute by appending a colon and the name of the stream to the file name (for instance : AppxManifest.xml:WofCompressedData), and you have a big limit on the stream size. > > Here is an example of some files I found. They all seem to have the > 0x40000 attribute. Sometimes the EA points to a package name. This is interesting. Maybe 0x40000 (whose purpose I do not know) can be used to tell whether a file is a Windows system file which is not eligible for Linux extended attributes. ntfs-3g does not use the EA's at all. Microsoft probably use them in the update process, so better not to interfere. Consequently they are probably not eligible for extended attributes either (but checking for EA presence would be heavy for this purpose). [...] Jean-Pierre |
|
From: Jean-Pierre A. <jea...@wa...> - 2021-01-11 14:54:49
|
Akshay Ajayan wrote on 1/11/21 1:52 PM: > Hi, > > I found the following bug while mounting a corrupt image using ntfs-3g. > > Bug info: > Infinite loop in ntfs_volume_startup at volume.c:602 > This bug occurs because of incorrect value of LCN of VCN 0 of the $MFT, > image offset 0x30 in $Boot. Thank you for having already debugged the cause. I think I just have to add another condition in the consistency check of the boot sector. And a reminder : there is a backup boot sector in the last sector of the partition, it can be retrieved by ntfsfix when the normal boot sector is corrupt. Jean-Pierre > > Behavior in windows: Disk structure is corrupted and unreadable > > Version info: > r00tus3r@akshay:~$ ntfs-3g --version > ntfs-3g 2017.3.23 integrated FUSE 27 > > To Reproduce: > ntfs-3g loop.img mountpoint > > Please let me know if you need the corrupted image file or any > additional information. > > Best, > Akshay |
|
From: Douglas P. <do...@bo...> - 2021-01-11 14:45:50
|
Hello, I noticed in the documentation (and confirmed with some random pages of MS documentation) that reparse points are not supposed to be supported when there are extended attributes. This doesn't seem to be true anymore, at least for files that use 'WofCompressedData' and also come from a package. Should there be any danger to remove the check for EAs when setting reparse data, or maybe it should only be done for 'small' reparse tags? I noticed this when trying to manipulate files with reparse data to properly copy them. What I was doing was removing the reparse data, so symlinks could be copied correctly with the correct type (file or directory), and the reapply it after. For WofCompressed files, I planned to copy the data using the "streams_interface=windows" option because sometimes the data is too large to pass with xattr. However, this failed because after the reparse attribute was removed, it could not be put back. Here is an example of some files I found. They all seem to have the 0x40000 attribute. Sometimes the EA points to a package name. thorx /mnt/c # find | while read i ; do ~doug/working/ntfs/ea_and_reparse "$i" ; done ./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml ./Program Files/WindowsApps/Microsoft.Windows.Photos_2020.20110.11001.0_neutral_split.scale-100_8wekyb3d8bbwe/resources.pri ./Program Files/WindowsApps/Microsoft.LanguageExperiencePackfr-FR_19041.12.29.0_neutral__8wekyb3d8bbwe/Windows/System32/Speech/Engines/SR/fr-FR/srloc.dll.mui ^C thorx /mnt/c # getfattr -h -n system.ntfs_ea -e text "./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml" # file: Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml system.ntfs_ea="P\000\000\000\0000\000$KERNEL.PURGE.ESBCACHE\0000\000\000\000\000��@<��fB�ps�\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000<\000\000\000\000\000$KERNEL.PURGE.APPXFICACHE\000��@<��u�\000\000\000\000\000\000\000\000\000\000\000\000" thorx /mnt/c # getfattr -h -n system.ntfs_ea -e hex "./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml" # file: Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml system.ntfs_ea=0x5000000000163000244b45524e454c2e50555247452e4553424341434845003000000003000206dd1407a0403ccd01806642a57073d301020000001200120200000000000000000000000000000000003c00000000191800244b45524e454c2e50555247452e415050584649434143484500dd1407a0403ccd01c075e7870200000000000000000000000000 thorx /mnt/c # getfattr -h -n system.ntfs_reparse_data -e hex "./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml" # file: Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml system.ntfs_reparse_data=0x170000801000000001000000020000000100000002000000 thorx /mnt/c # stat "./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml" File: c/./Program Files/WindowsApps/Microsoft.MicrosoftSolitaireCollection_4.8.12113.0_x64__8wekyb3d8bbwe/AppxManifest.xml -> unsupported reparse point Size: 25 Blocks: 0 IO Block: 4096 symbolic link Device: 812h/2066d Inode: 18478 Links: 2 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-01-10 00:19:49.545437200 -0500 Modify: 2021-01-10 00:19:49.545437200 -0500 Change: 2021-01-10 00:19:49.561056900 -0500 Birth: - thorx /mnt/c # cd .. thorx /mnt # umount c thorx /mnt # ntfsinfo /dev/sdb2 -i 18478 --force WARNING: Dirty volume mount was forced by the 'force' mount option. Dumping Inode 18478 (0x482e) Upd. Seq. Array Off.: 48 (0x30) Upd. Seq. Array Count: 3 (0x3) Upd. Seq. Number: 4 (0x4) LogFile Seq. Number: 0x36e7c2d1a MFT Record Seq. Numb.: 14 (0xe) Number of Hard Links: 2 (0x2) Attribute Offset: 56 (0x38) MFT Record Flags: IN_USE Bytes Used: 848 (0x350) bytes Bytes Allocated: 1024 (0x400) bytes Next Attribute Instance: 10 (0xa) MFT Padding: 00 00 Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 0 (0x0) Data size: 72 (0x48) Resident flags: 0x00 File Creation Time: Sun Jan 10 05:19:49 2021 UTC File Altered Time: Sun Jan 10 05:19:49 2021 UTC MFT Changed Time: Sun Jan 10 05:19:49 2021 UTC Last Accessed Time: Sun Jan 10 05:19:49 2021 UTC File attributes: ARCHIVE SPARSE_FILE REPARSE_POINT UNKNOWN: 0x00040000 (0x00040620) Maximum versions: 0 Version number: 0 Class ID: 0 User ID: 0 (0x0) Security ID: 9892 (0x26a4) Quota charged: 0 (0x0) Update Sequence Number: 10870027712 (0x287e775c0) Dumping attribute $FILE_NAME (0x30) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 3 (0x3) Data size: 90 (0x5a) Resident flags: 0x01 Parent directory: 52860 (0xce7c) File Creation Time: Sun Jan 10 05:19:49 2021 UTC File Altered Time: Sun Jan 10 05:19:49 2021 UTC MFT Changed Time: Sun Jan 10 05:19:49 2021 UTC Last Accessed Time: Sun Jan 10 05:19:49 2021 UTC Allocated Size: 0 (0x0) Data Size: 0 (0x0) Filename Length: 12 (0xc) File attributes: ARCHIVE (0x00000020) Namespace: DOS Filename: 'APPXMA~1.XML' Dumping attribute $FILE_NAME (0x30) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 2 (0x2) Data size: 98 (0x62) Resident flags: 0x01 Parent directory: 52860 (0xce7c) File Creation Time: Sun Jan 10 05:19:49 2021 UTC File Altered Time: Sun Jan 10 05:19:49 2021 UTC MFT Changed Time: Sun Jan 10 05:19:49 2021 UTC Last Accessed Time: Sun Jan 10 05:19:49 2021 UTC Allocated Size: 0 (0x0) Data Size: 0 (0x0) Filename Length: 16 (0x10) File attributes: ARCHIVE (0x00000020) Namespace: Win32 Filename: 'AppxManifest.xml' Dumping attribute $DATA (0x80) from mft record 18478 (0x482e) Resident: No Attribute flags: 0x8000 Attribute instance: 4 (0x4) Compression unit: 4 (0x4) Data size: 13468 (0x349c) Allocated size: 65536 (0x10000) Initialized size: 13468 (0x349c) Compressed size: 0 (0x0) Dumping attribute $DATA (0x80) from mft record 18478 (0x482e) Resident: No Attribute name: 'WofCompressedData' Attribute flags: 0x0000 Attribute instance: 7 (0x7) Compression unit: 0 (0x0) Data size: 3432 (0xd68) Allocated size: 4096 (0x1000) Initialized size: 3432 (0xd68) Dumping attribute $REPARSE_POINT (0xc0) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 5 (0x5) Data size: 24 (0x18) Resident flags: 0x00 Reparse tag: 0x80000017 (Wof compressed) Data length: 16 (0x10) Data: 0x01000000020000000100000002000000 Dumping attribute $EA_INFORMATION (0xd0) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 8 (0x8) Data size: 8 (0x8) Resident flags: 0x00 Packed EA length: 129 (0x81) NEED_EA count: 0 (0x0) Unpacked EA length: 140 (0x8c) Dumping attribute $EA (0xe0) from mft record 18478 (0x482e) Resident: Yes Attribute flags: 0x0000 Attribute instance: 9 (0x9) Data size: 140 (0x8c) Resident flags: 0x00 End of inode reached Thanks, -- Douglas Paul |
11 messages has been excluded from this view by a project administrator.