search for: telldir

Since the d_off in the first dirent for "." (that originates from the 4th argument "offset" of filldir() for the 2nd dirent for "..") is wrongly assigned in btrfs_real_readdir(), telldir returns same offset for different locations. | # mkfs.btrfs /dev/sdb1 | # mount /dev/sdb1 fs0 | # cd fs0 | # touch file0 file1 | # ../test | telldir: 0 | readdir: d_off = 2, d_name = "." | telldir: 2 | readdir: d_off = 2, d_name = ".." | telldir: 2 | readdir: d_off =...

I was just playing with git 1.5.3.8 and btrfs 0.11, and I noticed something odd. If I prepare a very simple repository: $ mkdir foo $ cd foo $ git init Initialized empty Git repository in .git/ $ echo hi > blort $ git add . $ git commit -m create Created initial commit 4ae9415: create 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 blort and then

On Mon, Feb 27, 2023 at 08:01:40PM +0100, Conor Armstrong wrote: > I think it has a lot to do with telldir on an NFS share returning a cookie > that is supposed to be unique rather than an actual offset. Problem is, > that cookie is stored as a 31bit hash which can then end up as a negative > signed offset in Samba which is not handled correctly. The cookies are not > necessarily con...

I think it has a lot to do with telldir on an NFS share returning a cookie that is supposed to be unique rather than an actual offset. Problem is, that cookie is stored as a 31bit hash which can then end up as a negative signed offset in Samba which is not handled correctly. The cookies are not necessarily consecutive as you move through...

...ms that have version 1 naming the last entry in that directory listing has a dirent->d_off value of -1 if you treat it as a long. On systems with version 2 naming the value is not set to -1. In samba 3.0.11 there was no apparent test of the dirent->d_off field, but in 3.0.12 it performs a telldir after reading the last name and returns NULL if the offset it -1. My understanding is that if you preform a telldir after the readdir, as is found in ReadDirName() in dir.c for 3.0.12+ you are just getting the offset for the next entry. So after the last entry in the directory you will be getti...

...Offset: -376809161586095012 File: 3507, Offset: -376809161585570724 ... The negative NFS negative offsets seem to be managed already in source3/smbd/dir.c in the map_dir_offset_to_wire() function which adjusts for signed/unsigned longs. You mention that NFS doesn't have a working seekdir()/telldir()/rewinddir(). Other than the different offset (cookie) management, do you know of any other differences? I had a look at the wireshark dumps. I'm getting a STATUS_PENDING shortly followed by a STATUS_CANCELLED for the NFS share which are absent on the block storage share. > On Wed, Feb 1...

...-376809161585570724 > > ... > > The negative NFS negative offsets seem to be managed already > in?source3/smbd/dir.c in the?map_dir_offset_to_wire() function which > adjusts for signed/unsigned longs. > You mention that?NFS doesn't have a working > seekdir()/telldir()/rewinddir(). Other than the different offset (cookie) > management, do you know of any other differences? > I had a look at the wireshark dumps. I'm getting a STATUS_PENDING shortly > followed by a STATUS_CANCELLED for the NFS share which are absent on the > block storage...

...ow this issue has arisen a few times over the past couple of years and > never any real resolution.? Would be good to get it solved once and for > all. Samba is merely making opendir()/readdir()/closedir() calls in a loop in this codepath. It's possible we may also be using seekdir() telldir()/rewinddir() calls, which may not be returning a consistent view of the directory over NFS. Get debug level 10 logs plus a wireshark trace to see what is going on both in the fileserver and on the wire. ----- End forwarded message -----

Alternately, we could possibly modify the dptr_TellDir function to set a flag somewhere if it ever returns a negative offset. Then any calls to dptr_SeekDir checks if the flag is set and does a slower approach of a RewindDir and then multiple ReadDir & TellDir calls until we get the matching offset. If flag is not set then go with the normal SeekD...

...gt; this might allow for some code to use array indexes instead of NFS cookies > as noted by Chris Chilvers here for the 3.10 kernel: > [1]https://lore.kernel.org/all/CAAmbk-e-YQAPo6QyNB0aJyc9qzUShmEC+x5eTR7wqp1ABWADsg at mail.gmail.com/T/ First I think we need to understand how broken telldir()/seekdir() is over NFS in this case. Do they work at all ? An alternate fix would be to change Samba to store the previously read filename on the STATUS_MORE_ENTRIES case (we've run out of return space) and then when the enumeration starts again use that stored filename, rather than doing the...

...nsigned range allowed by NFS cookie for > > READDIR > > and READDIRPLUS. > > > > The issue is that this 64 unsigned value is used for the directory's > > file > > position (d_off), which is a 64 bit signed value. This can cause > > readdir and > > telldir to return negative values. > > Known issue that we had to deal with 25 years ago for 32 bit systems > when glibc first decided to make lseek() return signed values (struct > old_linux_direct still has it as an unsigned value). > > So VAST have had a long time to learn not to do th...

...d as NFS. No other protocols are supported (eg CIFS or AFS). Anyway the sshfs intermediate mount worked for me but it would be good to have this issue addressed in Samba. On Mon, 27 Feb 2023 at 20:01, Conor Armstrong <conorarmstrong at gmail.com> wrote: > I think it has a lot to do with telldir on an NFS share returning a cookie > that is supposed to be unique rather than an actual offset. Problem is, > that cookie is stored as a 31bit hash which can then end up as a negative > signed offset in Samba which is not handled correctly. The cookies are not > necessarily consecutive...

On Wed, Feb 15, 2023 at 08:06:28PM +0100, Conor Armstrong wrote: > Rowland & Jeremy - thanks for this! > I built a copy of the latest version from github 4.19 and same issue > arises. ? > I will have a look at the wireshark trace and see if I can spot anything > obvious there. > I'm not an expert on this, but as far?as I know NFS isn't fully POSIX >

Hi, A stupid flat directory /tmp holding 5 millon files, the directory locates on a ext3 file system with dir_index feature turned on. The running Linux are FC4 and FC5. The files are just directly under /tmp, not in any subdirectories -- they are results of mis-operations of users. Then a 'ls' or 'find' command will take one hour to finish, a lot of other applications on

Hello, I have a problem with directories that contain more than 10000 entries (Ubuntu 8.04.1) or with more than 70000 entries (RHEL 5.2). If you use readdir(3) or readdir64(3) you get one entry twice, with same name and inode. Some analyzing showed that disabling dir_index solves this problem, but I think that this is a bug in the ext3 code, as no other file-system shows this behavior.

Jeremy, I think we found the part of source where the problem resides: smbd/trans2.c +1444 for (i=0;(i<maxentries) && !finished && !out_of_space;i++) { +1445 BOOL got_exact_match = False; +1446 +1447 /* this is a heuristic to avoid seeking the dirptr except when +1448 absolutely necessary. It allows for

...a wrote: > > > > OK, almost certainly it's the NFS mount causing the problem. > > > > Can you try and reproduce on a locally hosted share. > > > > I expect not. Given it's on an NFS mount, we can investigate > > but I'm guessing it'll be the telldir()/seekdir() error that > > seems to be endemic to NFS mounts. > > > > It will not help using the REALM instead of the WORKGROUP in the idmap > config lines. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions:...

Hello, I have a Samba 3.0.24 server running on a NetBSD 3.1 (i386) box, which has been very reliable for a long time, but recently started to occasionally show the following error on PC's connected to it running XP Pro and AutoDesk (AutoCAD) files: z:\ is not available Not enough storage is available to process this command log.smbd shows this when it happens : [2007/06/08 10:01:50, 0]

We have Win98 DOS (4.11.2222) clients that exhibit behaviors thought to have been corrected. They are running the MS-CLIENT redirector. 3.0.11 will do a directory listing correctly and show all entries in upper case. 3.0.14a gets stuck in a dir loop with the client and displays non-mangled names in lower case. 3.0.20rc2 gets stuck in a dir loop with the client and displays all entries in upper

...fs objects = acl_xattr full_audit doing parameter map acl inherit = Yes doing parameter store dos attributes = Yes doing parameter full_audit:prefix = %u|%I|%m|%S doing parameter full_audit:success = mkdir rename unlink rmdir write doing parameter full_audit:failure = read pread mkdir opendir rmdir telldir doing parameter full_audit:facility = local7 doing parameter full_audit:priority = NOTICE pm_process() returned Yes Registered MSG_REQ_POOL_USAGE Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED lp_load_ex: refreshing parameters Initialising global parameters Processing section "[global]"...