FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sun Jun 20, 2021 03:21



Post new topic Reply to topic  [ 5 posts ] 
Getting and setting DOS names 
Author Message

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Getting and setting DOS names
Hi,

It's me again, from the thread about applying a WIM image to NTFS. Today I was trying to get wimlib working with the 2013.1.13 release of libntfs-3g, and I noticed that the handling of DOS names in libntfs-3g has been changed. As stated in another thread, this is to avoid a bug.

Could this bug potentially affect wimlib linked with libntfs-3g 2012.1.15 or earlier? Note that the basic handling of extracting the filenames by my code was, essentially, to repeat the following three steps for each directory in which a file had names:

1. call ntfs_create() to create the file with its first name if the file was
not already created, otherwise call ntfs_link(); either way, always choose the
long name with an associated short name (if any) in the case of multiple
long names in the same directory.

2. call ntfs_set_ntfs_dos_name() if the long name created had an associated
short name

3. call ntfs_link() to create any additional names in the same directory

Probably I've still been doing something wrong due to the intricacies of the namespaces, but either way, in the new release of libntfs-3g the setting/getting of DOS names on files with multiple (long) names appears to no longer be supported (supposedly for a good reason). Are you planning to fix this functionality in a future release of NTFS-3g, or would you suggest that I just ignore DOS names on multi-linked files? I'm fine with either way, since I'm under the impression that the DOS names are obsolete and virtually useless anyway... But for completeness, it might be nice to handle them correctly.

Thanks!


Wed Jan 30, 2013 09:01
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Getting and setting DOS names
Hi,

Quote:
I was trying to get wimlib working with the 2013.1.13 release of libntfs-3g, and I noticed that the handling of DOS names in libntfs-3g has been changed. As stated in another thread, this is to avoid a bug.

Yes. Unfortunately, the old code has led to damaging two file systems, and I have had to add restrictions. The origin of the issue is the fact that the kernel designates a file by its inode number, not by its name. As a consequence, when using fuse, ntfs-3g may, in adverse situations, get a file name which is not the one which the program had stated.
Quote:
Could this bug potentially affect wimlib linked with libntfs-3g 2012.1.15 or earlier?

No, when creating ntfs files from a wim file, provided you did as was agreed before, but probably
Yes, when creating a wim file from an ntfs file tree (not sure, may depend on using fuse)
Quote:
1. call ntfs_create() to create the file with its first name if the file was
not already created, otherwise call ntfs_link(); either way, always choose the
long name with an associated short name (if any) in the case of multiple
long names in the same directory.

I think I said : first create the file with the long name, then create the associated short name, then create the remaining names. The important thing is to create the short name when the long name is the only existing name, so that there cannot be any ambiguity for the couple "long name + short name". Probably if the file already existed, you should do a full "rename" to force the long name as the only existing name.
At the end of step 1 the file has to have a single name, and this is the long name.
Quote:
in the new release of libntfs-3g the setting/getting of DOS names on files with multiple (long) names appears to no longer be supported (supposedly for a good reason). Are you planning to fix this functionality in a future release of NTFS-3g

Currently you still can set a dos name to a file with multiple names provided you use the (same) correct sequencing.

I still have not found a way for getting the dos name (and identifying the associated long name) for a file with multiple names. However the root of the issue is making the request through the kernel, and if wimlib is dynamically linked to libntfs-3g, the issue vanishes.
Quote:
I'm under the impression that the DOS names are obsolete and virtually useless anyway... But for completeness, it might be nice to handle them correctly.

I agree. I have to review the code to make a proposal for programs which link to libntfs-3g. This should be new entries similar to old ones with new names.

Regards

Jean-Pierre


Mon Feb 04, 2013 14:03
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Getting and setting DOS names
Hi,

Thanks for the response! wimlib is dynamically linked to libntfs-3g and does not rely on the FUSE interface to NTFS-3g for either WIM creation or extraction, although I was using it for some of the test cases, which I never experienced any problems with. (A couple test cases did involve DOS names on multi-linked files, and these fail with the new version of NTFS-3g so I will remove or replace them.)

wimlib does use FUSE to provide the ability to mount WIM images, but this does not use NTFS-3g at all, and I also don't allow getting/setting DOS names on files in a mounted WIM image.

Is it true that a file can have only 1 DOS name total, rather than 1 DOS name per directory? If so, this might simplify things a little bit.

Quote:
Currently you still can set a dos name to a file with multiple names provided you use the (same) correct sequencing.


I had been trying to do this, but ntfs_link() seemed to fail with EIO when trying to create another name for a file that had just been created with a long and associated short name with ntfs_create() followed by ntfs_set_ntfs_dos_name(). The next time I work on this I'll try to track down the issue (perhaps it was something unrelated).

Quote:
I still have not found a way for getting the dos name (and identifying the associated long name) for a file with multiple names. However the root of the issue is making the request through the kernel, and if wimlib is dynamically linked to libntfs-3g, the issue vanishes.


Yes, wimlib is dynamically linked with libntfs-3g so this should theoretically be a non-issue, although as mentioned, the behavior of some of the libntfs-3g external interfaces (e.g. ntfs_get_ntfs_dos_name()) have been changed despite the fact that they can be accessed from non-FUSE code.

As an alternative, would it be possible for me to use the DOS names when they're returned by the ntfs_readdir() callbacks, thereby avoiding ntfs_get_ntfs_dos_name() entirely? I originally thought this wouldn't work because there can be multiple long names in a directory, but thinking about it now, I should be able to tell which one the short name goes with because the name_type parameter provided to the filldir function distinguishes Win32 and Win32+DOS names from POSIX names. Note that currently I am already using ntfs_readdir(), but am ignoring any DOS names returned, then querying them separately with ntfs_get_ntfs_dos_name(). So it actually would make more sense to use the DOS name entries from ntfs_readdir(), although I might have to buffer DOS names that are returned before the corresponding Win32 name, if that can happen.

Quote:
I have to review the code to make a proposal for programs which link to libntfs-3g. This should be new entries similar to old ones with new names.


I don't know the planned release schedule for NTFS-3g, but I'm assuming it would be a while before a new release would be made. So I would like to update wimlib to be compatible with ntfs-3g_2013.1.13. I suppose in the best case, I could use ntfs_readdir() as I suggested above which would remove the ntfs_get_ntfs_dos_name() call entirely, and I could still set DOS names on multi-linked files (as you indicated should still be possible) by fixing possible sequencing issues, provided I didn't uncover some other problem by the EIO error I mentioned above. So ideally, I wouldn't even need any new interfaces to provide full support for DOS names for both WIM apply and capture. I'll see, though!

Thanks again!


Tue Feb 05, 2013 04:55
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Getting and setting DOS names
Hi,

Quote:
Is it true that a file can have only 1 DOS name total, rather than 1 DOS name per directory? If so, this might simplify things a little bit.

Yes. Windows only supports a single dos name per file.
Quote:
As an alternative, would it be possible for me to use the DOS names when they're returned by the ntfs_readdir() callbacks, thereby avoiding ntfs_get_ntfs_dos_name() entirely? I originally thought this wouldn't work because there can be multiple long names in a directory, but thinking about it now, I should be able to tell which one the short name goes with because the name_type parameter provided to the filldir function distinguishes Win32 and Win32+DOS names from POSIX names. Note that currently I am already using ntfs_readdir(), but am ignoring any DOS names returned, then querying them separately with ntfs_get_ntfs_dos_name().

At first glance, this should be possible. The only recent change in ntfs_readdir() is filling the dt_type field.
Quote:
I might have to buffer DOS names that are returned before the corresponding Win32 name, if that can happen.

This probably happens, as the return order is defined by how the names are located in the directory index.
Quote:
So ideally, I wouldn't even need any new interfaces to provide full support for DOS names for both WIM apply and capture. I'll see, though!

This would be ideal for me also...

Regards

Jean-Pierre


Tue Feb 05, 2013 12:55
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Getting and setting DOS names
All right, I think I've solved all my problems (for now). I get the DOS names via ntfs_readdir() by building a per-directory red-black tree that maps NTFS inode numbers to DOS names (or Win32+DOS names), then going through the WIM dentries after the ntfs_readdir() call to assigning the appropriate short name to each WIM dentry created from a Win32 or Win32+DOS name attribute. So that gets rid of the ntfs_get_ntfs_dos_name() calls.

The error in ntfs_link() I observed seemed to be caused by my code closing the inodes in the wrong order. I apparently broke it when I tried to simplify my code a while back. With the fix I just added, it works fine to ntfs_link() to an inode that has had a DOS name set with ntfs_set_ntfs_dos_name().

I should do some additional testing, but at this point it seems I don't need any new interfaces in libntfs-3g.

Thanks!


Wed Feb 06, 2013 00:21
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 


Who is online

Users browsing this forum: No registered users 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

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.