On Windows XP, when I run find against "Documents and Settings" or any of its subdirectories, it works as expected. However if I run it against any other directory, including the root (C:) I receive the following message:
find: cannot get current directory: Permission denied
I've tried fiddling with the file permissions to match those in Documents and Settings, but this had no effect.
I'm running:
GNU find version 4.2.20
Features enabled: CACHE_IDS D_TYPE
Any help would be appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Somewhere in the back of my mind I remember a similar problem. The problem was Pagefile.sys or the hibernat.sys files... They are always opened by the operating system. Try to disable hibernation and also move the pagefile to another disk/partition if you have one. The problem should then go away...
-micor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Windows XP, when I run find against "Documents and Settings" or any of its subdirectories, it works as expected. However if I run it against any other directory, including the root (C:) I receive the following message:
find: cannot get current directory: Permission denied
I've tried fiddling with the file permissions to match those in Documents and Settings, but this had no effect.
I'm running:
GNU find version 4.2.20
Features enabled: CACHE_IDS D_TYPE
Any help would be appreciated.
Here are three cases:
C:\Documents And Settings>find
.
./Administrator
./Administrator/Application Data
./Administrator/Application Data/desktop.ini
[...snip...]
C:\>find
.
find: .: Permission denied
C:\temp>find
find: cannot get current directory: Permission denied
=====================
Interestingly (?) stat . works fine from all three locations, and returns results like this:
File: `.'
Size: 0 Blocks: 0 IO Block: 4096 directory
Device: 66cc9ef4h/1724686068d Inode: 1125899906844028 Links: 14
Access: (0666/drw-rw-rw-) Uid: ( 0/ bnewsom) Gid: ( 0/ UNKNOWN)
Access: 2005-03-31 16:15:28.484375000 -0500
Modify: 2005-03-31 12:13:29.656250000 -0500
Change: 2004-12-13 14:16:34.147562900 -0500
I'm running XP-SP1. Thanks...
I also have this problem.
findutils-4.2.20-2.exe
steps to reproduce:
c:
cd \
find
.
find: .: Permission denied
Note the results of stat:
c:
cd \
stat .
File: `.'
Size: 0 Blocks: 0 IO Block: 4096 directory
Device: c01d9260h/3223163488d Inode: 1407374883553285 Links: 28
Access: (0666/drw-rw-rw-) Uid: ( 0/ User1) Gid: ( 0/ UNKNOWN)
Access: 2005-04-30 22:56:57.095651200 -0400
Modify: 2005-04-30 22:48:00.123523200 -0400
Change: 2003-08-26 07:56:35.913732800 -0400
Is the Inode too big?
I am logged in as user1 with Admin rights with XP Professional sp2.
Please help.
Thanks,
WR
Additional info:
findutils-4.2.20-2.exe
NTFS c: 80GB drive (21 GB available)
Computer is part of a workgroup only
This works
stat "c:\documents and settings"
This doesn't (all fail Permission denied)
find c:\
find "c:\"
find "c:\documents and settings"
TIA,
WR
Another test:
This works:
cd \documents and settings
find
This doesn't work
c:
cd \
find "c:\documents and settings"
ERROR: Permission denied
This does work
C:
cd \
stat "c:\documents and settings"
-WR
I cannot reproduce these problems, under the same setup (user with Admin rights under WinXP-Pro SP2). All the examples work.
The inode is not too big: it is a 64-bit number, and given number (0x5000000000005) fits in this size.
Somewhere in the back of my mind I remember a similar problem. The problem was Pagefile.sys or the hibernat.sys files... They are always opened by the operating system. Try to disable hibernation and also move the pagefile to another disk/partition if you have one. The problem should then go away...
-micor
I cannot reproduce this on WinXP Pro SP2. Exacly what command do you give, and what is the supposed result?
I am running Win2k and get the same thing.
Also NTFS.
C:\find . -name CVS
find: cannot get current directory: Permission denied
FWIW, find works fine on any FAT filesystem on my system - it just fails as described on NTFS