In case it matters: I stumbled over this problem when backing up a directory using rsync in a Cygwin environment, and rsync suddenly gave the error message:
rsync: readdir("/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb"): File exists (17)
Here, /cygdrive/d/portable/FirefoxPortable is the directory to be saved, and until now, this has worked fine. Suspecting that the real problem is not related to rsync, I did a
ls /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
and indeed got the error message
ls: reading directory '/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb': File exists
So, idb is a directory (which is true), because ls says that it is reading this direcory, but why do I get a File exists error for a directory?
ls -ld /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
yields
drwxr-xr-x 1 FISRONA Domain Users 0 May 6 2019 '/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb'
and
stat /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
displayed:
File: /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
Size: 0 Blocks: 0 IO Block: 65536 directory
Device: 5a61dfech/1516363756d Inode: 12873190524118251466 Links: 1
Access: (0755/drwxr-xr-x) Uid: (3672028/ FISRONA) Gid: (1049089/Domain Users)
Access: 2019-05-06 11:32:50.000000000 +0200
Modify: 2019-05-06 11:32:50.190000000 +0200
Change: 2019-05-06 11:32:50.190000000 +0200
Birth: 2019-05-06 11:32:50.190000000 +0200
What could be messed up here to cause this behaviour?
BTW, I also checked the parent directory (because sometimes, differences in upper/lower case filenames can result in odd effects under Cygwin, due to the underlying Windows operating system):
ls -l /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/
total 0
drwxr-xr-x 1 FISRONA Domain Users 0 May 6 2019 idb
Related
I'm using Centos 8.0 and my kernel version:
4.18.0-147.5.1.x86_64
Backgroud:
The messages on my host not rotated for a long time,and when I use "logrotate -v -f" to force rotating messages, it shows "rename messages: Operation not permitted".So I try renaming the messages immediately.
-rw------- 1 root 15464299992 Jul 15 10:12 messages
-rw------- 1 root 11644353 Sep 7 2020 messages-20200907.gz
-rw------- 1 root 8834073 Sep 13 2020 messages-20200913.gz
renaming /var/log/messages to /var/log/messages-20210715
error: failed to rename /var/log/messages to /var/log/messages-20210715: Operation not permitted
Here is my operation and the terminal's output:
[root#node-5 log]# mv messages messages-20210715
mv: cannot move ‘messages’ to ‘messages-20210715’: Operation not permitted
[root#node-5 ~]# whoami
root
I login as root,why do I still come across such problem? How can I solve this?
#DavidC.Rankin
Thx for replying.Here is the ls -ald . for messages:
[root#node-5 log]# ls -ald
drwxr-xr-x. 30 root 8192 Jul 15 11:14 .
So I don't think this may be a problem about permissions.
I also used strace to follow the syscall:
stat("messages2", 0x7fff6c37aae0) = -1 ENOENT (No such file or directory)
lstat("messages", {st_mode=S_IFREG|0600, st_size=15464637645, ...}) = 0
lstat("messages2", 0x7fff6c37a790) = -1 ENOENT (No such file or directory)
renameat2(AT_FDCWD, "messages", AT_FDCWD, "messages2", 0) = -1 EPERM (Operation not permitted)
Unfortunately,there are too many branches in function do_renameat2 so I haven't found the exact exit yet.
The problem got solved:
Show the file attributes with lsattr, it seems that messages got an attribute 'a',so it can't be renamed.
---------------- ./maillog-20201004
-----a---------- ./messages
And with command chattr -a messages,messages can be renamed again.
A symbolic link created by zfs is returning as ../../zd0, tested through multiple ways to check. Not sure why the result is not /dev/zd0 as that is the actual link as far as I am aware.
admin#r2-compute1:~$ ls -l /dev/zvol/cpool/cinder-volumes
lrwxrwxrwx 1 root root 9 Jun 25 09:53 /dev/zvol/cpool/cinder-volumes -> ../../zd0
admin#r2-compute1:~$ stat /dev/zvol/cpool/cinder-volumes
File: /dev/zvol/cpool/cinder-volumes -> ../../zd0
Size: 9 Blocks: 0 IO Block: 4096 symbolic link
Device: 6h/6d Inode: 640 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-06-25 10:07:28.610707769 -0700
Modify: 2020-06-25 09:53:52.174435310 -0700
Change: 2020-06-25 09:53:52.174435310 -0700
Birth: -
admin#r2-compute1:~$ file /dev/zvol/cpool/cinder-volumes
/dev/zvol/cpool/cinder-volumes: symbolic link to ../../zd0
I am working with openstack and zfs and am wondering why the symbolic link returns "../../zd0" instead of "dev/zd0". I am not sure what the ../../ means and understanding would assist in my openstack implementation understanding. First time posting and Google and SymbolHound did not produce any results in regards to the meaning behind ../../
Thank you!
Probably while creating the soft links ../../zd0 was adopted instead of the full path /dev/zd0 (or whatever the path was supposed to be given).
If absolutely necessary, you may try to unlink this first and recreate the link by providing FULL-PATH to the DEVICE/FILE.
NOTE: Try this with caution and ensure the paths are correct, this is just the symbolic code to help you correct the error:
unlink /dev/zvol/cpool/cinder-volumes
ln -s /dev/zvol/cpool/cinder-volumes /dev/zd0
I have implemented a new NAS filer recently, and after mounting
it on a Linux server, the Perl interpreter (version 5.005_03) is unable
to recognize the existence of files on that mount:
[root#server ~]# stat /newmount/testfile
File: `/newmount/testfile'
Size: 0 Blocks: 0 IO Block: 65536 regular empty file
Device: 48h/72d Inode: 9262698097446760736 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 500/ testuser) Gid: ( 500/ testuser)
Access: 2017-02-22 16:44:21.218314000 +0200
Modify: 2017-02-22 16:44:21.218314000 +0200
Change: 2017-02-22 16:44:21.218314000 +0200
[root#server ~]# perl -e 'print "File Exists\n" if -e "/newmount/testfile";'
[root#server ~]#
The interesting thing here, is this:
When I try with a newer version of the
interpreter (like perl, v5.8.8) it works:
[root#server ~]# perl -e 'print "File Exists\n" if -e "/newmount/testfile";'
File Exists
[root#server ~]#
What am I missing on the old Perl?
Thanks in advance!
Thanks for anyone trying to help, I found the root cause of the issue.
For anyone facing a similar issue with legacy systems,
check if the storage exporting the NFS mounts is using 64-bit file descriptors.
In my case, switching to 32-bit file descriptors on the storage solved the issue.
I had a similar issue while using Perl.
The mounted nfs directory had perms of 775 and ownership of 0:788
Account running Perl had primary GID of 402 and was also a member of 788.
Error messages indicated "does not exist or is not a directory"
I changed the primary group of the active account to 788 and it began working.
Only posting in the hopes of preventing someone else from ripping out their last remaining hairs.
I am running Centos 7 kernel 3.10.0 on Oracle's VirtualBox 4.3.20 with an ext4 filesystem.
It seems that setting the "A" flag on a file doesn't keep the access time field from updating.
I created a file and used stat to check the access time -
touch ./foo
stat ./foo
which returns the following
File: ./foo
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd01h/64769d Inode: 1444417 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 1000/ user_1) Gid: ( 1000/ user_1)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2015-08-02 11:52:23.451524456 -0700
Modify: 2015-08-02 11:52:23.451524456 -0700
Change: 2015-08-02 11:52:23.451524456 -0700
Birth: -
If I then change the attribute and rerun stat -
sudo chattr +A ./foo
stat ./foo
I get the following which (I think) shows the access time value as updated?
File: ./foo
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd01h/64769d Inode: 1444417 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 1000/ user_1) Gid: ( 1000/ user_1)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2015-08-02 11:53:32.400974020 -0700
Modify: 2015-08-02 11:53:32.400974020 -0700
Change: 2015-08-02 11:53:32.400974020 -0700
Birth: -
Am I misunderstanding the use of the A flag? I thought it would keep the access time from changing?
Thanks for any insights you can offer. I am just trying to understand how things work.
Rog
+A will keep the same atime when you open the file with vi for example and not modify it. The result you've posted after modifying the attribute doesn't look right to me. Changing the attribute should only affect the 'Change' timestamp. In your case, all 3 timestamps are the same.
I am studying the linux file system. I had an experiment to explore how linux saves the hard links.
I made 1000 hard links for a file in the same directory. The size of .(DOT) increased to 28672; I remove 500 hard links, the size of .(DOT) did not decrease. (I used "stat ." to check the size.) Why doesn't the size decrease?
This is my experiment:
I have a folder named test, which has only one small file testfile and a script, the status was like this:
York:~/test$ ll -li
total 84
7995940 drwxr-xr-x 2 York domain_users 4096 Jul 17 19:20 ./
7995939 drwxr-xr-x 3 York domain_users 69632 Jul 17 19:20 ../
7996494 -rwxrwxrwx 1 York domain_users 94 Jul 17 19:14 copy.sh*
8026281 -rw-r--r-- 1 York domain_users 7 Jul 17 19:17 testfile
York:~/test$ stat .
File: `.'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:20:06.288345960 +0200
Modify: 2015-07-17 19:20:05.420340318 +0200
Change: 2015-07-17 19:20:05.420340318 +0200
Birth: -
Then I ran the script:
for i in `seq 200000 200999`;
do
ln testfile "$i"
done
After that, I got the following result:
York:~/test$ stat .
File: `.'
Size: 28672 Blocks: 64 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:21:25.364862751 +0200
Modify: 2015-07-17 19:21:11.064768884 +0200
Change: 2015-07-17 19:21:11.064768884 +0200
Birth: -
And I could see that the inode counter is 1001, which was what I expected:
York:~/test$ ll -li testfile
8026281 -rw-r--r-- 1001 York domain_users 7 Jul 17 19:17 testfile
I used "rm" to remove 500 hard links, I saw:
York:~/test$ ll -li testfile
8026281 -rw-r--r-- 501 York domain_users 7 Jul 17 19:17 testfile
But the size of the directory did not decrease:
York:~/test$ stat .
File: `.'
Size: 28672 Blocks: 64 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:24:35.138125221 +0200
Modify: 2015-07-17 19:24:35.142125246 +0200
Change: 2015-07-17 19:24:35.142125246 +0200
Birth: -
My understanding about the directory in file system is like this: For each directory, an inode is allocated for attributions like folder name etc, and also a block of data is used to keep entries for files and directories in that folder. Because each hard link needs one entry, 1000 hard links need more space than a block of data, another data blocks are needed. So the size of the directory .(DOT) increases. Vise versa, if I remove 500 hard links, the size should decrease.
But the experiment showed that the size did not decrease. Where am I wrong?
Thank you in advance!
Best Wishes,
York
What you're seeing is correct. Many Linux filesystems never shrink the size of a directory inode; they just blank out the entries for deleted files, allowing them to be reused if more files are added to the directory later. The only way to return the directory to its original size may be to delete it and create a new one with the same name.
Frequently, inodes are implemented on b-trees and as a minor optimization, the can grow as needed, but don't collapse.