dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1037
share rss forum feed


mazhurg
Premium
join:2004-05-02
Brighton, ON
Reviews:
·MTS

[Parts Check] NAS long file name support

Anyone can recommend a good home network NAS that can handle windows long file names properly (NFTS > 220 chrs)?

The N2200Plus that I currently have keeps choking on windows file history as quite a few of the files that I have are nested quite deep and have long (and descriptive) names.

Thanks.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 edit

Did you mean >256 bytes (not the same as characters) as the full path (not the same as the filename)? If so:

»stackoverflow.com/questions/1857···-in-ntfs

Please read all the comments. You will see that Unicode (and which type, i.e. UTF-8 vs. UTF-16) plays a role as well.

Welcome to NTFS, and welcome to Windows.

My advice to you, if you must use NTFS (most of the time you don't have a choice on Windows desktop systems), is to stop nesting things so deep. It's akin to telling your doctor "it hurts when I put 500 pounds of weight on my legs"; they're going to say "then stop doing that".

I would normally have said "make this Thecus Technology's problem" (since what you have is a vendor lock-in / "black box" solution), but this looks to be more of a limitation of NTFS being imposed by you on the system you have the NAS hooked to, rather than the NAS. The NAS itself appears to use XFS as its own native filesystem for storing the filesystem you've put on the NAS (hard to explain how this works, sorry). See very bottom of "Specs" page:

»www.thecus.com/product.php?PROD_ID=43

I'm going to recommend to mods that this thread be moved to the Microsoft Help forum instead, as they may be able to give you workarounds/advice depending on what OS version you run and so on.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



mazhurg
Premium
join:2004-05-02
Brighton, ON
Reviews:
·MTS

Thanks much for the answer. Yes, the issue appears to be with file paths. The latest problem occurred with a simple file copy of the \steam (and associated data) folder, residing at the root of the drive.

I was transferring the content of the above folder via the NAS to a portable.

While the copy to the NAS appears to have worked, the NAS-> portable was constantly timing out but eventually appears to have completed (I've yet to ensure that the files did copy properly).

Knowing that it takes a long time to use Windows to tell a NAS to delete 300,000+ files, I SSHd to the NAS and went to do an RM -r on the copied steam folder. The operation failed with multiple cannot "stat" errors on associated long filepaths.

I then tried to do a file system check on the NAS drive (via a reboot and umounted volume) however the operation does not appear to be proceeding as of this writing (almost 24 hrs in).

Searching on this type of issue yesterday I am unsure but it seems that the problem is not so much in either NFTS nor the XFS capability at the local device level but on how Windows (8-64 bits) transfer the files over a network.

In the end, it might be that one has to go trough the inconvenience of backup volumes vice straight folder copies, but one would think that if a NAS permit mounting as a network drive that it would have the same capabilities than a local drive.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 edit

Thanks for the explanation.

What's confusing me even more now is the fact that you SSH'd to the NAS directly and then issued presumably rm -fr on a folder. Do you have a way to determine if that folder was part of an NTFS filesystem (rather than XFS)? If this is a Linux-based system, simply run "mount" and provide the full output here, and state exactly what path/directory you were on the NAS when you issued the (presumably) rm -fr command.

Why the cabling/setup/etc. matters with regards to filesystems:

You can have a directory on the NAS exported via Samba (i.e. CIFS/SMB), which on a Windows machine (over the LAN) you could be mounting as a drive letter (say E:, i.e. you're mounting \\nas\something as E:). In that case NTFS is not used, unless the actual filesystem on the NAS itself used for the storage of that directory is NTFS (which sounds unlikely, re: documentation says XFS). Furthermore, if this was the case, you would have been receiving errors from Windows (or a game, etc.) when trying to read those files with "long paths" -- the same kind of underlying file I/O is done both locally from the NAS as well as via Samba.

Now, if you've hooked the NAS up via USB, that's a different story. In that case the NAS would have to have some kind of native device/block level support, allowing you (under Windows) to format a volume (created by the NAS, which would probably be a single file on the local NAS filesystem) as NTFS. The NAS could possibly also mount that file as a filesystem (quite easy on Linux), even if it's NTFS. In that NTFS path length limitations would apply.

So at this point I still don't have enough evidence/technical data shown to me to indicate if this is a NAS issue, an NTFS issue, or what.

Speaking generally -- yes, NTFS will let you create files/dirs that exceed the path length limit, yet if you try to read those files/dirs will fail. I've experienced it myself on my XP machine. Microsoft still does not appear to know how to design filesystems, and likewise applications (games etc.) which are exceeding the path length limit are just as awful. It shows a lack of familiarity with technology in general (especially in the latter case).

P.S. -- The "stat" errors you see can be the cause of many things (it would help if you gave the actual error output, not just "stat". The error would have been something like stat(): {long path name}: error string). rm -fr has to iterate recursively over directories; the contents of those directories can change in real-time. For example, if you were issuing a delete of a very large folder on the NAS at the same time as running rm -fr on the same folder, you would see a certain kind of error, while filesystem-level errors would show up as a different error.

P.P.S. -- You should be aware Steam has its own native way of backing up games which is usually what you should use. Within Steam: Steam menu -> Backup and Restore Games.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



mazhurg
Premium
join:2004-05-02
Brighton, ON
Reviews:
·MTS

Click for full size
said by koitsu:

Thanks for the explanation.

What's confusing me even more now is the fact that you SSH'd to the NAS directly and then issued presumably rm -fr on a folder. Do you have a way to determine if that folder was part of an NTFS filesystem (rather than XFS)? If this is a Linux-based system, simply run "mount" and provide the full output here, and state exactly what path/directory you were on the NAS when you issued the (presumably) rm -fr command.

Mount output:

N2200Plus:~# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw,relatime,errors=continue)
tmpfs on /dev/shm type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
proc on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
/dev/loop0 on /usr/lib type squashfs (ro,relatime)
/dev/loop1 on /usr/share/zoneinfo type squashfs (ro,relatime)
/dev/loop2 on /opt type squashfs (ro,relatime)
/dev/mtdblock3 on /etc type jffs2 (rw,noatime,nodiratime)
/dev/vg0/lv0 on /raid0 type xfs (rw,noatime,nodiratime,attr2,noquota)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
N2200Plus:~#

said by koitsu:

Why the cabling/setup/etc. matters with regards to filesystems:

You can have a directory on the NAS exported via Samba (i.e. CIFS/SMB), which on a Windows machine (over the LAN) you could be mounting as a drive letter (say E:, i.e. you're mounting \\nas\something as E:). In that case NTFS is not used, unless the actual filesystem on the NAS itself used for the storage of that directory is NTFS (which sounds unlikely, re: documentation says XFS). Furthermore, if this was the case, you would have been receiving errors from Windows (or a game, etc.) when trying to read those files with "long paths" -- the same kind of underlying file I/O is done both locally from the NAS as well as via Samba.

Drive is not mounted as letter but directly accessed as a share via file manager: (see picture above not the subject NAS but similar- sorry my HTML skills are not too great to place the picture here).

The folder Public_disk is in /raid0 (/dev/vg0/lv0). In any case, it looks like I am going to have to rebuild the array as while the Thecus manager shows a healthy raid, it appears to have lost all the share folders (manager - web based times out ) and changing directory to /raid0 via SSH shows a ls of .

N2200Plus:/# cd /raid0
N2200Plus:/raid0# ls
ls: .
N2200Plus:

and

N2200Plus:/dev/vg0# ls
lv0@
N2200Plus:/dev/vg0#

It will not let me umount the drive so I can run a xfs_repair on it.

N2200Plus:/# umount -f /raid0
umount: forced umount of /raid0 failed!
umount: cannot umount /raid0: Device or resource busy
N2200Plus:/#

Yet there is nothing connected to it.

-----------------------------

I do thank you for the help and insight though.

said by koitsu:

So at this point I still don't have enough evidence/technical data shown to me to indicate if this is a NAS issue, an NTFS issue, or what.

Speaking generally -- yes, NTFS will let you create files/dirs that exceed the path length limit, yet if you try to read those files/dirs will fail. I've experienced it myself on my XP machine. Microsoft still does not appear to know how to design filesystems, and likewise applications (games etc.) which are exceeding the path length limit are just as awful. It shows a lack of familiarity with technology in general (especially in the latter case).

I am finding this the hard way

said by koitsu:

P.S. -- The "stat" errors you see can be the cause of many things (it would help if you gave the actual error output, not just "stat". The error would have been something like stat(): {long path name}: error string). rm -fr has to iterate recursively over directories; the contents of those directories can change in real-time. For example, if you were issuing a delete of a very large folder on the NAS at the same time as running rm -fr on the same folder, you would see a certain kind of error, while filesystem-level errors would show up as a different error.

No, rm was run from the parent folder. In any case, since I am no longer able to access the /raid0 file system I won't be able to show the error output. The only 2 log files in /var/log are log.nmbd and log.smbd which do not have file level errors. As the NAS is linux based, I do not know where any other error logs would reside.

As this is the 3rd time (in as many months) that this is happening, I have no critical data on the drive so I will probably reformat (again). However it really does not give me a warm feeling for a backup system. I have also a Qnap (209 pro) and a NAS200 (Linksys) that have worked for years, however file transfer has always been too slow (2-4 Mbps) and are not used much anymore when GB of transfers are required.

said by koitsu:

P.P.S. -- You should be aware Steam has its own native way of backing up games which is usually what you should use. Within Steam: Steam menu -> Backup and Restore Games.

Last time I used this app it was a real PIA as every game had to be individually selected and selecting too many at once would result in a backup, or restore failure.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1. The filesystem used by the NAS is XFS. NTFS is not involved.

2. The model you're using in the screenshot is CIFS/SMB. NTFS is not involved.

3. The filesystem is mounted as /raid0, and appears to be managed by a volume manager (possibly LVM -- don't know, have no familiarity with LVM). I can tell from the fact that it's /dev/vg0/lv0 (LV stands for "logical volume").

4. There's nothing in /dev for you to look at -- no sense going there.

5. The umount -f failed either because a) there are still daemons/processes/etc. that are referencing filehandles on that volume (I'm aware -f is supposed to trump that, but there may be kernel-level tie-ins that would cause a kernel panic if this were to succeed), or b) there's a LVM in use

At this point, plain and simple: you need to talk to the vendor (Thecus Technologies) and make this their problem. They are the only ones who can help with this. By purchasing a vendor lock-in/black-box product, you have to rely entirely 100% on them to provide answers.

The volume failure you've encountered (missing data, etc.) you will need to engage Thecus about as well. If this has happened in the past (sounds like it has), I would be pushing very VERY hard on technical support to provide assistance/a solution. Why people tolerate this is beyond me... Thusly: the stat errors you saw during rm -fr are probably the result of filesystem or underlying disk issues.

Back to path names: we know factually XFS has no pathname limitations, so that means the 256-byte limitation is a CIFS/SMB path name limit (I just looked this up and it appears it also has the same limit NTFS does -- they're separate things though). I do not know if the UNC name (i.e. \\NAS\public_disk) contributes to the total CIFS/SMB path length; I'm thinking it doesn't.

Regarding NASes in general -- this is why I build my own, using server-class hardware and OSes I'm familiar with. My data is my responsibility, and I do not trust a "vendor" with my data.

You might find this post on an unrelated forum worth noting -- specifically that the WD My Book Live uses Linux (with Samba) and gets pretty decent performance. There is a WD My Book Live Duo as well (which contains 2 disks in a RAID fashion; don't know what RAID implementations it uses). I have no familiarity with these devices -- but the author of that post is one of the key maintainers of the Entware project and is a software developer/hacker (including sometimes at the kernel level). I'm inclined to believe him. But yes, this is another vendor lock-in/black-box device.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



mazhurg
Premium
join:2004-05-02
Brighton, ON

1 recommendation

Thanks for your help, there was enough info for me to be able to further search and I was able to recover all the files, and fix the raid volume.