digitalmars.D - std.file.listdir doesn't work on directory NTFS directory mounted by NTFS-3G
- miraks (7/7) Feb 24 2007 Hi,
- Frits van Bommel (3/14) Feb 24 2007 Does 'ls' show different results in the directories? Case differences
- miraks (6/21) Feb 24 2007 It's not due to different cases.
- mike (9/17) Feb 24 2007 Works perfectly with NTFS for me, on Windows. Maybe wrong slashes in the...
- miraks (5/5) Feb 24 2007 You are right, it works perfectly if mounted with "ntfs" but not with "n...
- Daniel Keep (20/31) Feb 24 2007 The source code for std.file.listdir comes with the DMD archive; after
- Walter Bright (4/18) Feb 24 2007 You don't need to convert it to C. Just instrument the source code and
- miraks (6/6) May 18 2007 I understood why it doesn't work with NTFS-3G.
Hi, I am on MANDRIVA 2007 and I am using NTFS-3G to mount NTFS directory. When I use the following code on a directory containing mp3 files: auto d_source_files = std.file.listdir(args[1], "*.mp3"); The list is empty. If I launch the same code on the same data but on a FAT32 disc, then the result is the expected one. Why std.file.listdir works on FAT32 and not on NTFS ?
Feb 24 2007
miraks wrote:Hi, I am on MANDRIVA 2007 and I am using NTFS-3G to mount NTFS directory. When I use the following code on a directory containing mp3 files: auto d_source_files = std.file.listdir(args[1], "*.mp3"); The list is empty. If I launch the same code on the same data but on a FAT32 disc, then the result is the expected one. Why std.file.listdir works on FAT32 and not on NTFS ?Does 'ls' show different results in the directories? Case differences maybe? (i.e. .MP3 vs .mp3)
Feb 24 2007
Frits van Bommel Wrote:miraks wrote:It's not due to different cases. I tried auto d_source_files = std.file.listdir(args[1], "*"); In this case, the list is not empty. The list contains only the direct child directories. Conclusion: The "recursive" mode doesn't work on NTFS disc. In fact,Hi, I am on MANDRIVA 2007 and I am using NTFS-3G to mount NTFS directory. When I use the following code on a directory containing mp3 files: auto d_source_files = std.file.listdir(args[1], "*.mp3"); The list is empty. If I launch the same code on the same data but on a FAT32 disc, then the result is the expected one. Why std.file.listdir works on FAT32 and not on NTFS ?Does 'ls' show different results in the directories? Case differences maybe? (i.e. .MP3 vs .mp3)
Feb 24 2007
Am 24.02.2007, 12:22 Uhr, schrieb miraks <s.mankowski miraks.com>:Hi, I am on MANDRIVA 2007 and I am using NTFS-3G to mount NTFS directory. When I use the following code on a directory containing mp3 files: auto d_source_files =3D std.file.listdir(args[1], "*.mp3"); The list is empty. If I launch the same code on the same data but on a FAT32 disc, then t=he =result is the expected one. Why std.file.listdir works on FAT32 and not on NTFS ?Works perfectly with NTFS for me, on Windows. Maybe wrong slashes in the= = path or so. -Mike -- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Feb 24 2007
You are right, it works perfectly if mounted with "ntfs" but not with "ntfs-3g". The problem is may be due to "ntfs-3g". Something is strange, because some application like "EasyTag" works well (with recusivity) on the same directory mounted with "ntfs-3g". It's may be an incompatibility D/ntfs-3g.
Feb 24 2007
miraks wrote:Hi, I am on MANDRIVA 2007 and I am using NTFS-3G to mount NTFS directory. When I use the following code on a directory containing mp3 files: auto d_source_files = std.file.listdir(args[1], "*.mp3"); The list is empty. If I launch the same code on the same data but on a FAT32 disc, then the result is the expected one. Why std.file.listdir works on FAT32 and not on NTFS ?The source code for std.file.listdir comes with the DMD archive; after giving it a quick look, it looks like it's just using ordinary linux calls: specifically, opendir and readdir. I find it somewhat hard to believe that the code would work on one filesystem but not another if Phobos was at fault (kind of like a program failing to load because your room is painted blue instead of green -- it shouldn't matter). If you're up to it, you might want to try translating the code to C and see if it does the same thing. If it does, then it's an OS problem; if it doesn't, then something's screwy with Phobos. If that's not an option, since the source for the function is there, you can always copy the code and make sure that the various functions are returning the expected values. I can't do much more to help, since I don't run Linux :3 Good luck. -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Feb 24 2007
Daniel Keep wrote:It works on NTFS under Windows, I know, I use it.Why std.file.listdir works on FAT32 and not on NTFS ?The source code for std.file.listdir comes with the DMD archive; after giving it a quick look, it looks like it's just using ordinary linux calls: specifically, opendir and readdir. I find it somewhat hard to believe that the code would work on one filesystem but not another if Phobos was at fault (kind of like a program failing to load because your room is painted blue instead of green -- it shouldn't matter). If you're up to it, you might want to try translating the code to C and see if it does the same thing. If it does, then it's an OS problem; if it doesn't, then something's screwy with Phobos. If that's not an option, since the source for the function is there, you can always copy the code and make sure that the various functions are returning the expected values.You don't need to convert it to C. Just instrument the source code and see where it is going wrong.
Feb 24 2007
I understood why it doesn't work with NTFS-3G. With NTFS-3G, the attribute isdir of DirEntry is always 0 (FALSE). The methode isdir() work as expected. It's why listdir doesn't work, because of based in isdir. I put in place a workaround but take care if you use DirEntry.isdir. I replaced e.isdir by isdir(e.name).
May 18 2007