 |
  |
Page 1 of 1
|
[ 21 posts ] |
|
Problems with non-Engliss symlinks
| Author |
Message |
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
 Problems with non-Engliss symlinks Dear Tuxera, i tried upgrading my Fedora from ntfs-3g 4.4, but soon noticed that driver fails (14.11 or R21, no matter). Especially this happens in folders containing NTFS symlinks (*not* vista), resulting general protection fault or libc.2 segmentation fault in /var/log/message The first symptom is that the entire directory starting Junction (except entries before) becomes red and names starting from '?' symbol (they aren't, actually). Next, the mount become unavailable. Trying getattr on symlink makes the enire system lock-up. All symlinks on tome do contain Cyrillic chars (stock utility, from the Resource Kit, doesn't allow that, but i have my own one, works perfectly on XP  The code in 14.11 isn't well commented, but enough to see that symlinks are feed in ntfschar, and then "fixed" to cpuchar (byte). See reparse.c But this is completely wrong! NTFS volume might actually contain paths in national charsets (all UTF-8), it's not rare. ntfs-3g is surely misinterpreting em. Can you fix it, please? Otherwise all except US, AU and UK residents are in possible trouble. -- My second suggestion is all about dates. The main differences between ext2 and NTFS is that the last one has three different fields instead of two. This makes an NTFS extremely flexible on archival storage, file sorting etc. Unfortunately, I was unable locating any info on dates in 'extended attributes' section on site, but the ctime should still reside somewhere, in fact dir.c uses it. And samba wraps xattrs, at least for ACLs. I am unsure if SMB contains all three (atime, ctime and mtime), but losing this functionality is a real drawback, especially for netwok backup.
|
| Mon Nov 30, 2009 22:57 |
 |
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, Quote: i tried upgrading my Fedora from ntfs-3g 4.4, but soon noticed that driver fails (14.11 or R21, no matter). Especially this happens in folders containing NTFS symlinks (*not* vista), resulting general protection fault or libc.2 segmentation fault in /var/log/message Please post the offending symlink data, by issuing the following command : Quote: getfattr -h -e hex -n system.ntfs_reparse_data <directory-name> Quote: Trying getattr on symlink makes the enire system lock-up. Be sure to use the option -h on getfattr, so that the link is not interpreted. Quote: The code in 14.11 isn't well commented, but enough to see that symlinks are feed in ntfschar, and then "fixed" to cpuchar (byte). See reparse.c But this is completely wrong!
[...]
NTFS volume might actually contain paths in national charsets (all UTF-8), it's not rare. Ok. Never saw that, I always got UTF16 (created by Vista). Could you detail how they were created ? This is the more strange as there is a tag to differentiate the formats. Quote: Can you fix it, please? Sure, but I need details and examples. Are you using a virtual operating system hosted by another type of operating system ? Quote: Unfortunately, I was unable locating any info on dates in 'extended attributes' section on site, but the ctime should still reside somewhere, in fact dir.c uses it. ntfs-3g uses three dates the same way as ext2/ext3 : mtime, atime and ctime (this is last change time). They are all returned by stat(2). Windows does not use the change time, but uses a creation time. They are all four maintained by ntfs-3g. What is your problem ? Quote: I am unsure if SMB contains all three (atime, ctime and mtime), but losing this functionality is a real drawback, especially for netwok backup. Which is the lost functionnality ? Regards Jean-Pierre **edit** A bug related to time stamps has been reported recently. It has been fixed in the beta-test advanced version : http://pagesperso-orange.fr/b.andre/dow ... 14AB.1.tgzYour problem may be related. Can you check whether the be beta version fixes it ?
|
| Wed Dec 02, 2009 23:23 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, Quote: (stock utility, from the Resource Kit, doesn't allow that, but i have my own one, works perfectly on XP I did not notice that at first reading, but it may explain the behavior. Windows XP does not support the symlinks, so it does not process a symlink with a target coded as UTF8.... and bad luck, a relative symlink has no device unit prefix on which a sanity check can be applied. When you post the reparse data, I will check how Vista interprets it, and I will do accordingly. Just note I will not be able to work on it for a few days. Regards Jean-Pierre
|
| Thu Dec 03, 2009 10:58 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-English symlinks Then, i tried 11.14-AB.1. jpa wrote: Hi, Quote: Please post the offending symlink data, by issuing the following command : Quote: getfattr -h -e hex -n system.ntfs_reparse_data <directory-name> Quote: Trying getattr on symlink makes the enire system lock-up. Be sure to use the option -h on getfattr, so that the link is not interpreted. I can restore it by memory, because i did it some years ago. The link actually is a five-component one, Cyrillic and Latin mixed, K:\Видео\AMV\Music\Song\.готовые\ with '.' preceeding many directory names (incl. the link itself) When first posted, i got in /var/log/messages: Nov 30 22:02:47 localhost kernel: mount.ntfs-3g[30198] general protection ip:3765a74605 sp:7fffab66f790 error:0 in libc-2.11.so[3765a00000+16f000] Now: "Software caused connection abort", with a volume became misfunctional yet not unmounted So still problematic. - Then i have created and connected a pure, 500 Gb test volume with some data. NTFS-3G did translated and performed just like ln -s: /mnt/wd_500/Видео I created .NTFS-3G in root filesystem (correct?), and placed P:\Видео here (the link contents, points to some folder) However, instead of translation it does look to a local volume's wd_500/Видео, a subdirectory of which the link actually is. Different volumes can have the same structure, but they aren't the same! # file: .\320\263\320\276\321\202\320\276\320\262\321\213\320\265 system.ntfs_reparse_data=0sAwAAoCYAAAAAABoAHAAAAFwAPwA/AFwAUAA6AFwAEgQ4BDQENQQ+BFwAAAAAAA== The directory where it does reside is: /mnt/wd_500/Видео/Рабочие I don't think that a such a behavior is right in fact there can be a bunch of split \Video or \Sound pairs on different volumes, created & distributed due to a lack of space. My personal case is that source video files are located on a first physical volume, and project results are fed to a second one. Top path parts can be exactly the same, though. However, because the translation algorithm has been already declared, maybe adding a global mount parameter limiting from two-stage translation to a "global", system-wide one ? (step #2 only) - And - surprise! - a translated link not shown in SAMBA (at the same time, a non-root owner can access the link via console. Regular SMB ln's are ok) Quote: Windows XP does not support the symlinks The link has been created in Win2K that does support junctions (in fact, mine are absolute - never needed of relative ones) **edit** Still, no mtime can be changed through Samba without touching ctime. Ctime, actually, cannot be changed at all (changes together with mtime, and with ls -la --time=ctime command, ctime seems to reflect the last attribute change time, not the attribute itself) Regards,
|
| Thu Dec 03, 2009 23:59 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks And yes, the first - problematic - link includes whitespaces:
'K:\Видео\AMV\Band\A Some Composition\.готовые', to be correct
|
| Fri Dec 04, 2009 00:03 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, Quote: I can restore it by memory, because i did it some years ago.
The link actually is a five-component one, Cyrillic and Latin mixed,
K:\Видео\AMV\Music\Song\.готовые\
with '.' preceeding many directory names (incl. the link itself) Please post the FULL reparse data in hex. I want to see the tag, the flags, the pointers, the display format. There is probably a flag meaning local coding. I also see that this is not UTF8, and in this case there is a device unit on which a check can be made (though "K:" has a UTF16 meaning). If this were a relative link with no device or leading "..", there is no obvious check. Quote: I created .NTFS-3G in root filesystem (correct?), and placed P:\Видео here (the link contents, points to some folder)
However, instead of translation it does look to a local volume's wd_500/Видео, a subdirectory of which the link actually is. If you do not encode the symlink as UTF16, you will not get correct results. There is no situation in NTFS where local encoding is used. Quote: Still, no mtime can be changed through Samba without touching ctime. Ctime, actually, cannot be changed at all (changes together with mtime, and with ls -la --time=ctime command, ctime seems to reflect the last attribute change time, not the attribute itself) Strange. What are you protection settings ? utime() checks the ownership of the file, whereas creation of the file is related to parent directory protections, this sometimes leads to timestamps not being updated. I have no time now. I will work on it on Monday. Regards Jean-Pierre
|
| Fri Dec 04, 2009 08:11 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, I have replayed the following example (the only one you gave with the full reparse data). Quote: # file: .\320\263\320\276\321\202\320\276\320\262\321\213\320\265
system.ntfs_reparse_data=0sAwAAoCYAAAAAABoAHAAAAFwAPwA/AFwAUAA6AFwAEgQ4BDQENQQ+BFwAAAAAAA==
The reparse data decodes as : Code: 000000 030000A0 26000000 00001A00 1C000000 ....&...........
000010 5C003F00 3F005C00 50003A00 5C001204 \.?.?.\.P.:.\...
000020 38043404 35043E04 5C000000 0000 8.4.5.>.\..... This clearly indicates an UTF16 link, so my previous comments about UTF8 encoding were out of track. I copied your reparse data by : Code: setfattr -h -v 0sAwAAoCYAAAAAABoAHAAAAFwAPwA/AFwAUAA6AFwAEgQ4BDQENQQ+BFwAAAAAAA== -n system.ntfs_reparse_data disk/linux/setrep with disk/linux/setrep being an existing directory. Then I requested the display of the symlink : Code: [linux@pavilion2 ntfs-3g]$ ls -l disk/linux/setrep
lrwxrwxrwx 1 linux linux 46 2009-12-07 09:02 disk/linux/setrep -> ../.NTFS-3G/P:/Видео/ This appears to me as expected. The Windows symlink has been translated to a Linux symlink using what is defined in directory .NTFS-3G for P: To be really useful, you still have to define .NTFS-3G/P: or .NTFS-3G/P:/Видео as symbolic links to where these paths should lead to, as ntfs-3g cannot guess what mountpoints correspond to Windows device letters. Quote: I don't think that a such a behavior is right in fact there can be a bunch of split \Video or \Sound pairs on different volumes, created & distributed due to a lack of space. My personal case is that source video files are located on a first physical volume, and project results are fed to a second one. Top path parts can be exactly the same, though. However, because the translation algorithm has been already declared, maybe adding a global mount parameter limiting from two-stage translation to a "global", system-wide one ? (step #2 only) For an absolute symlink like this, a link in .NTFS-3G is first examined. Guesses on the same volume are only tried when there is no indication, so you always have the option of refusing the guesses. That is the main difference between your situation and mine, /Видео has probably been found on your volume, and the guess was wrong. By defining .NTFS-3G/P: there will be no guess. This is not possible for relative symlinks. They have no device letter, but their target is always on the same volume. As I was on a wrong track before, can you please detail again the situation which led to a segfault ? Please post the full reparse data returned by the command Code: getfattr -h -e hex -n system.ntfs_reparse_data <dir-path> So far, I have not been able to replicate the segfault, cyrillic chars or spaces should not harm. Regards Jean-Pierre **edit** The reparse data tag is "030000A0", so this is actually a junction point (directory or volume junction), not a symlink (symlinks are not supported by XP).
|
| Mon Dec 07, 2009 10:40 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks Thank you, jpa wrote: Hi,
This clearly indicates an UTF16 link, so my previous comments about UTF8 encoding were out of track.
I have explored it, too. The AttrDef$ of '.готовые' definitely is UTF-16, and it's a backslash ('\') terminated. Quote: This is not possible for relative symlinks. They have no device letter, but their target is always on the same volume.
Of course. But they aren't relative. Quote: Code: getfattr -h -e hex -n system.ntfs_reparse_data <dir-path> So far, I have not been able to replicate the segfault, cyrillic chars or spaces should not harm. Unfortunately, there's no any output produced - only session/system lock-up. (some times was unable to reboot even with a separate 'root' login) The only idea i have that volume got nearly full (actually, it is), and AttrDef$ fits the extent, not the main table. Or it's became non-resident. Is NTFS-3G handling a such a situation properly? P.S. I have reproduced nearly the same links on a test/clean volume, and got no problems. No grave problems arise, but... the translation is quite tricky. lrwxrwxrwx. user mygroup system_u:object_r:fusefs_t:s0 .готовые -> /mnt/wd_500/.NTFS-3G/P:/Видео/AMV/Stratovarius/Seasons of Change/.готовые/ Thus i need to recreate the entire directory structure, including drive, in /mnt/wd_500/.NTFS-3G to get it working. The manual surely needs to be clarified a bit: .NTFS-3G folder should reside on each of NTFS volumes, not in the root filesystem. [root@nas Seasons of Change]# pwd /mnt/wd_500/.NTFS-3G/P:/Видео/AMV/Stratovarius/Seasons of Change/.готовые -- I have checked also for ctime again. Seems to be a filesystem stat issue. Isn't easy to distinguish because SAMBA sets local attributes per single call (two versions actually available: name- and fd-based). And, in fact, there are 4 or 5 levels of nesting, indirect addressing, with a heavy call wrapping. Here's an excerpt: samba-3.4.2/source3/lib/time.cstatic time_t calc_create_time(const SMB_STRUCT_STAT *st) { time_t ret, ret1; ret = MIN(st->st_ctime, st->st_mtime); ret1 = MIN(ret, st->st_atime); if(ret1 != (time_t)0) { return ret1; } /* * One of ctime, mtime or atime was zero (probably atime). * Just return MIN(ctime, mtime). */ return ret; } ... But there's only one min(...) function for dates, and ctime mostly should be lower than mtime - at least, for 'ro'-mounted NTFS volumes. So still don't know, who's guilty. And yes, no fake date option used: ctime that i see via Network is not a beginning of epoch
|
| Mon Dec 07, 2009 16:03 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks The last thing is far more curious:
[root@nas .звуки]# stat --printf="\n\n* %n\nCtime=%z\nMtime=%y\nAtime=%x\n" *
* zvuk 9.mp3
Ctime=2009-12-03 19:49:42.000000000 +0300
Mtime=2006-06-06 10:16:38.000000000 +0400
Atime=2009-12-03 19:30:53.000000000 +0300
The bright line is exactly what the share did report first for a file being examined.
Then tried to change ctime 20 seconds less. Still no effect in directory list.
But,
[root@nas .звуки]# ls -la --time=ctime *
-rwxrwxrwx. 2 user group 227472 Dec 3 19:49 zvuk 9.mp3
then changed mtime via SMB (changing ctime still has no action)
[root@nas .звуки]# ls -la --time=ctime *
-rwxrwxrwx. 2 user group 227472 Dec 7 17:27 zvuk 9.mp3
So, ctime behavior is absolutely correct for Linux, yet not for NTFS: changing anything makes mtime be ALWAYS in past, constantly less than ctime.
Unfortunately, to get NTFS attributes working via share one may get rid of MIN(...) function from Samba completely. And/or changing also the default ntfs-3g timing behavior, in fact no ctime is set by a ctime change call itself. Just a system timestamp.
The more problematic is that is a server date, not a host one (as should be).
Another mount option needs to be passed to driver?
|
| Mon Dec 07, 2009 16:49 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks (And a path being translated still not shown to SAMBA. Seems to happen something wrong with attribute handling in fact a non-root console user *CAN* visit a link junction)
|
| Mon Dec 07, 2009 18:06 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks Excuze me, the last one is easily corrected by follow symlinks = yes, so please don't care
But a link cannot be seen unless is properly translated.
(v4.4 FUSE 2.70 came with FC12 listed symlinks as empty directories)
|
| Mon Dec 07, 2009 18:12 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, Quote: Unfortunately, there's no any output produced - only session/system lock-up. (some times was unable to reboot even with a separate 'root' login) Does this occur for all your junction points (symlinks) or only for some of them ? Are they correctly interpreted by Windows ? Did you make a chkdsk to rule out the possibility of garbled data ? If you know the device letter used in the junction point, it may be useful to define it in .NTFS-3G. This would be a second barrier against a loop in the links. Can you at least display the inode number (by "ls -li"). If you can, displaying the inode data may give some clue : Code: ntfsinfo -vi <inode-number> <unmounted-device> If that also fails, I will have to ask you make a metadata dump available, for me to analyze. Quote: The only idea i have that volume got nearly full (actually, it is), and AttrDef$ fits the extent, not the main table.
Or it's became non-resident.
Is NTFS-3G handling a such a situation properly? ntfs-3g has been developed with care, but it is very difficult to rule out the possibility of a bug having occurred in adverse conditions. Quote: lrwxrwxrwx. user mygroup system_u:object_r:fusefs_t:s0 .готовые -> /mnt/wd_500/.NTFS-3G/P:/Видео/AMV/Stratovarius/Seasons of Change/.готовые/ This is quite good, and leads me to suspect some garbled data in your real case. Quote: Thus i need to recreate the entire directory structure, including drive, in /mnt/wd_500/.NTFS-3G to get it working. In general, you need not create the full directory structure, you only have to link the needed device letters to the corresponding mountpoints. However this is only true when the junction points were defined with the correct letter cases. Quote: The manual surely needs to be clarified a bit: .NTFS-3G folder should reside on each of NTFS volumes, not in the root filesystem. Ok, I will improve that. And for the time stamp problems, can you open a different forum entry with a summary of your findings. It will be easier for other people (and for me also) to follow the case. Regards Jean-Pierre
|
| Mon Dec 07, 2009 19:48 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks jpa wrote: Hi, Quote: Unfortunately, there's no any output produced - only session/system lock-up. (some times was unable to reboot even with a separate 'root' login) Does this occur for all your junction points (symlinks) or only for some of them ? Absolutely all. The only way out is to kill a mount.ntfs-3g instance. Quote: Are they correctly interpreted by Windows ? Yes, they were fine before taken drives from a 1394 box. No HPA, checked. Quote: If you know the device letter used in the junction point, it may be useful to define it in .NTFS-3G. This would be a second barrier against a loop in the links.
I cannot can set drives to rw until sure that something never goes wrong... Quote: Can you at least display the inode number (by "ls -li"). If you can, displaying the inode data may give some clue : Code: ntfsinfo -vi <inode-number> <unmounted-device> If that also fails, I will have to ask you make a metadata dump available, for me to analyze. Here it is: Code: ----------------------------------------------------
Entry length: 96 (0x60)
Key length: 78 (0x4e)
Index entry flags: 0x00
FILE record number: 12447 (0x309f)
Parent directory: 495 (0x1ef)
File Creation Time: Tue Nov 25 20:40:35 2008
File Altered Time: Tue Nov 25 20:40:35 2008
MFT Changed Time: Wed May 6 01:44:55 2009
Last Accessed Time: Tue Nov 25 20:40:35 2008
Allocated Size: 0 (0x0)
Data Size: 0 (0x0)
Filename Length: 6 (0x6)
File attributes: REPARSE_POINT I30_INDEX (0x00000000)
Reparse point tag: 0xa0000003
Namespace: DOS
Filename: '427E~1'
And then: Code: -------------------------------------------------------------
Dumping Inode 12447 (0x309f)
Upd. Seq. Array Off.: 42 (0x2a)
Upd. Seq. Array Count: 3 (0x3)
Upd. Seq. Number: 32 (0x20)
LogFile Seq. Number: 0x7d048aee
MFT Record Seq. Numb.: 2 (0x2)
Number of Hard Links: 2 (0x2)
Attribute Offset: 48 (0x30)
MFT Record Flags: IN_USE DIRECTORY
Bytes Used: 592 (0x250) bytes
Bytes Allocated: 1024 (0x400) bytes
Next Attribute Instance: 5 (0x5)
MFT Padding:
Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 12447 (0x309f)
Attribute length: 96 (0x60)
Resident: Yes
Name length: 0 (0x0)
Name offset: 0 (0x0)
Attribute flags: 0x0000
Attribute instance: 0 (0x0)
Data size: 72 (0x48)
Data offset: 24 (0x18)
Resident flags: 0x00
ReservedR: 0 (0x0)
File Creation Time: Tue Nov 25 20:40:35 2008
File Altered Time: Tue Nov 25 20:40:35 2008
MFT Changed Time: Wed May 6 01:44:55 2009
Last Accessed Time: Tue Nov 25 20:40:35 2008
File attributes: REPARSE_POINT (0x00000000)
Maximum versions: 0
Version number: 0
Class ID: 0
User ID: 0 (0x0)
Security ID: 258 (0x102)
Quota charged: 0 (0x0)
Update Sequence Number: 0 (0x0)
Dumping attribute $FILE_NAME (0x30) from mft record 12447 (0x309f)
Attribute length: 104 (0x68)
Resident: Yes
Name length: 0 (0x0)
Name offset: 0 (0x0)
Attribute flags: 0x0000
Attribute instance: 3 (0x3)
Data size: 78 (0x4e)
Data offset: 24 (0x18)
Resident flags: 0x01
ReservedR: 0 (0x0)
Parent directory: 495 (0x1ef)
File Creation Time: Tue Nov 25 20:40:35 2008
File Altered Time: Tue Nov 25 20:40:35 2008
MFT Changed Time: Tue Nov 25 20:40:35 2008
Last Accessed Time: Tue Nov 25 20:40:35 2008
Allocated Size: 0 (0x0)
Data Size: 0 (0x0)
Filename Length: 6 (0x6)
File attributes: I30_INDEX (0x00000000)
Namespace: DOS
Filename: '427E~1'
Dumping attribute $FILE_NAME (0x30) from mft record 12447 (0x309f)
Attribute length: 112 (0x70)
Resident: Yes
Name length: 0 (0x0)
Name offset: 0 (0x0)
Attribute flags: 0x0000
Attribute instance: 2 (0x2)
Data size: 82 (0x52)
Data offset: 24 (0x18)
Resident flags: 0x01
ReservedR: 0 (0x0)
Parent directory: 495 (0x1ef)
File Creation Time: Tue Nov 25 20:40:35 2008
File Altered Time: Tue Nov 25 20:40:35 2008
MFT Changed Time: Tue Nov 25 20:40:35 2008
Last Accessed Time: Tue Nov 25 20:40:35 2008
Allocated Size: 0 (0x0)
Data Size: 0 (0x0)
Filename Length: 8 (0x8)
File attributes: I30_INDEX (0x00000000)
Namespace: Win32
Filename: '.Р_Р_С'Р_Р_С<Рч'
Dumping attribute $INDEX_ROOT (0x90) from mft record 12447 (0x309f)
Attribute length: 80 (0x50)
Resident: Yes
Name length: 4 (0x4)
Name offset: 24 (0x18)
Attribute name: '$I30'
Attribute flags: 0x0000
Attribute instance: 1 (0x1)
Data size: 48 (0x30)
Data offset: 32 (0x20)
Resident flags: 0x00
ReservedR: 0 (0x0)
Indexed Attr Type: DIRECTORY_I30
Collation Rule: 1 (0x1)
Index Block Size: 4096 (0x1000)
Clusters Per Block: 8 (0x8)
Entries Offset: 16 (0x10)
Index Size: 32 (0x20)
Allocated Size: 32 (0x20)
Index header flags: 0x00
Dumping index root:
Entry length: 16 (0x10)
Key length: 0 (0x0)
Index entry flags: 0x02
End of index block reached
Index entries total: 1
Dumping attribute $REPARSE_POINT (0xc0) from mft record 12447 (0x309f)
Attribute length: 144 (0x90)
Resident: Yes
Name length: 0 (0x0)
Name offset: 0 (0x0)
Attribute flags: 0x0000
Attribute instance: 4 (0x4)
Data size: 114 (0x72)
Data offset: 24 (0x18)
Resident flags: 0x00
ReservedR: 0 (0x0)
End of inode reached
------------------------------------------------------------------------- And a volume info, if it helps: Code: Volume Information
Name of device: /dev/sdc1
Device state: 11
Volume Name: Storage 1
Volume State: 1
Volume Version: 3.0
Sector Size: 512
Cluster Size: 65536
Volume Size in Clusters: 11446437
MFT Information
MFT Record Size: 1024
MFT Zone Multiplier: 1
MFT Data Position: 24
MFT Zone Start: 0
MFT Zone End: 1430806
MFT Zone Position: 2
Current Position in First Data Zone: 1430806
Current Position in Second Data Zone: 0
LCN of Data Attribute for FILE_MFT: 2
FILE_MFTMirr Size: 4
LCN of Data Attribute for File_MFTMirr: 5723218
Size of Attribute Definition Table: 2560
FILE_Bitmap Information
FILE_Bitmap MFT Record Number: 6
State of FILE_Bitmap Inode: 0
Length of Attribute List: 0
Attribute List: (null)
Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
Decompressed Runlist: not done yet
Base Inode: 6
Attribute Types: not done yet
Attribute Name Length: 0
Attribute State: 3
Attribute Allocated Size: 1441792
Attribute Data Size: 1430808
Attribute Initialized Size: 1430808
Attribute Compressed Size: 0
Compression Block Size: 0
Compression Block Size Bits: 0
Compression Block Clusters: 0
Quote: Quote: The only idea i have that volume got nearly full (actually, it is), and AttrDef$ fits the extent, not the main table.
Or it's became non-resident.
Is NTFS-3G handling a such a situation properly? ntfs-3g has been developed with care, but it is very difficult to rule out the possibility of a bug having occurred in adverse conditions. As now i see is resident. But yet don't know how to increase a verbosity level. Quote: Quote: lrwxrwxrwx. user mygroup system_u:object_r:fusefs_t:s0 .готовые -> /mnt/wd_500/.NTFS-3G/P:/Видео/AMV/Stratovarius/Seasons of Change/.готовые/ This is quite good, and leads me to suspect some garbled data in your real case. Yes, is a brand-new, nearly clear volume, just formatted in Windows. Last MFT entries are located in sector 0x200, or something like. Quote: And for the time stamp problems, can you open a different forum entry with a summary of your findings. It will be easier for other people (and for me also) to follow the case.
Yes, but it should require some time more.
|
| Mon Dec 07, 2009 21:40 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi,
Can you apply the attached patch (on ntfs-3g-2009.11.14AR.1) ?
This will not fix anything, but it will disable the interpretation of the reparse data in getattr(), hence you are unlikely to segfault when using getfattr to display the reparse data.
Regards
Jean-Pierre
|
| Tue Dec 08, 2009 09:44 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi,
I think I have found the bug. I confused a UTF16 length with a UTF8 length. Consequently a reserved buffer overflowed when using non-ascii chars.
Please try the attached patch against ntfs-3g-2009.11.14AR.1
Regards
Jean-Pierre
|
| Tue Dec 08, 2009 13:59 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi,
Same bug at another location, appended is an updated patch...
Sorry for the inconvenience.
Regards
Jean-Pierre
|
| Tue Dec 08, 2009 15:17 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks Okay, i'll try soon the latest one. jpa wrote: Please try the attached patch against ntfs-3g-2009.11.14AR.1
Did you mean actually "AB.1"? There's no AR.1 publicly available, only November's AR.19 and AR.22, both a bit outdated.
|
| Tue Dec 08, 2009 17:41 |
|
|
|
jpa
NTFS-3G Lead Developer
Joined: Tue Sep 04, 2007 17:22
Posts: 1008
|
Re: Problems with non-Engliss symlinks Hi, Quote: jpa wrote: Quote: Please try the attached patch against ntfs-3g-2009.11.14AR.1 Did you mean actually "AB.1"? There's no AR.1 publicly available Hmm, yes, sorry. Older versions were faulty for the same reason, but the patch will not apply to them. Regards Jean-Pierre
|
| Tue Dec 08, 2009 17:49 |
|
|
|
szaka
Tuxera CTO
Joined: Tue Nov 21, 2006 23:15
Posts: 1645
|
Re: Problems with non-Engliss symlinks This issue has been fixed in NTFS-3G 2010.1.16.
Thanks, Szaka
|
| Sun Jan 17, 2010 21:11 |
|
|
|
ELBY
Joined: Mon Nov 30, 2009 21:35
Posts: 38
|
Re: Problems with non-Engliss symlinks Oh, thank you. Please correct also revision story. The current text says: Quote: Fix: NTFS-3G may crashed if a junction point referred to a non-ASCII file. But it's not about text files - saying "ASCII file" means text file contents, indeed. It was a problem of multibyte, non-ANSI junction path targets; it's important for all non-Latin languages - Cyrillic, and especially for Chinese, Korean and Japanese (as i can imagine, at least)
|
| Sun Jan 24, 2010 13:04 |
|
|
|
szaka
Tuxera CTO
Joined: Tue Nov 21, 2006 23:15
Posts: 1645
|
Re: Problems with non-Engliss symlinks ELBY wrote: Please correct also revision story. The current text says: Quote: Fix: NTFS-3G may crashed if a junction point referred to a non-ASCII file. But it's not about text files - saying "ASCII file" means text file contents, indeed. It was a problem of multibyte, non-ANSI junction path targets; it's important for all non-Latin languages - Cyrillic, and especially for Chinese, Korean and Japanese (as i can imagine, at least) We use 'file' and 'filename' interchangeably. Filename is indeed the correct description everybody should clearly understand. Updated, thanks!
|
| Sun Jan 24, 2010 14:08 |
|
|
|
|
Page 1 of 1
|
[ 21 posts ] |
|
Who is online |
Users browsing this forum: Google [Bot] and 5 guests |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
|
|
|
