Intro Download and install Frequently Asked Questions Tips and tricks

Homepage







© J.C. Kessels 2009
MyDefrag Forum
May 24, 2013, 09:51:04 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: fsutil usn deletejournal /n c:  (Read 7943 times)
rich
JkDefrag Senior
****
Posts: 41


View Profile
« on: August 30, 2009, 02:06:12 am »

Another issue; even as an administrator, when I run the command prompt fsutil usn deletejournal /n c: it says "access denied". Any ideas? Thanks!

Rich
Logged
verdy_p
JkDefrag Hero
*****
Posts: 62


View Profile
« Reply #1 on: August 30, 2009, 02:20:48 am »

If you are running on Windows Vista or Seven, you may need to run it from a command line prompt with Administrator elevated privileges, not just the normal command prompt.

Or run it with LUAC disabled.
Logged
rich
JkDefrag Senior
****
Posts: 41


View Profile
« Reply #2 on: August 30, 2009, 02:58:13 am »

Did that! Still denied. Any other ideas?
Logged
verdy_p
JkDefrag Hero
*****
Posts: 62


View Profile
« Reply #3 on: August 30, 2009, 06:32:20 am »

Did that! Still denied. Any other ideas?
May be your NTFS partition was created by a domain administrator and prepared on another system: the local administrator doesnot have enough privileges in that case. You'll need to use the correct administrator to get the appropriate security token. Logon with it or use "RunAs" to start a command prompt with that user.
May be this administrative user no longer has an account on your system (you will see the in the security tab of the drive properties: there will be a user with full privileges, but just displayed with its numeric SID, instead of its name). This may also have happend because you have reinstalled Windows on top of an existing partition: the newly create adminsitrator is then distinct and has a distinct SID than the one that was used to create the partition.
If this is not the case, you may need to check the group policies that have been applied to your local admin; and then take ownership of the volume (using the security settings panel).

Then try looking at the security properties for the volume: make sure that the "Administrators" group owns the drive (try to give it the ownership of the drive), and that the builin user "SYSTEM" also has full privileges.

If everything fails, then it's possible that you have a malicious rootkit, that has impersonalized your existing Administrator, and took ownership of your system (the "Administrator" user name is just a name given to an account, it does not means it is necessarily THE system administrator). But don't do that if your system is a member of a domain, as it may invlidate yuor system from joining the domain (you'd have to ask gain to the domain admin to authorize yuor system).

Another thing you can investigate:
* First allow hidden directories to be displayed in the Explorer, including system files.
* Then look at the security properties of the "System Volume Information": try adding yourself to the list of users granted with full access rights. If you cannot do that (including when bootin in failsafe mode), then you are not the proper administrator.

There should exist a user listed in the Security tab for the volume, that has full privileges (in addition to the builtin "SYSTEM" user used by the Windows Kernel at boot, and that you must not remove, or the special "TrustedInstaller" user that only Microsoft owns and can use using its own secret keys to install or update Windows with Windows Update with digitally signed installation packages bearing this user in its signatures).
Logged
lh
JkDefrag Hero
*****
Posts: 83


View Profile
« Reply #4 on: August 31, 2009, 02:23:13 am »

Is your box perchance a Vista HP laptop?

I contacted HP on the issue and they told me that 'In this circumstance there would be nobody at HP that could help you with the issue as we are not trained on issues such as these.  This would be supported by microsoft, however because the operating system is a oem and not retailed version they may charge you for the support.'

They lock the thing down with something.  I could never get them to tell me what they did to the OS that would cause this.  I have so far seen at least 8 different HP laptops that have this issue.  None of the desktops do.  Doesn't matter if it is 64bit or 32bit.  It seems every other manufacture this works on *except* HP vista laptops.

See the previous discussion.  We tried just about everything...
http://www.mydefrag.com/forum/index.php?topic=1131.0

We ended up created a separate XP boot disk that would let us at the thing.  The downside is that it comes back after a reboot.  In the end I created a utility that gets at the USN in a different way so I did not need the separate boot disk.  It comes back almost instantly.  I still can not figure out what sys/dll/exe is recreating it.

The newest version of this defrag program has a DeleteJournal() action.  I have not tried it yet to see if it works in this condition.

There are also versions of Sysindexer, and Microsoft Messenger that lock this file.  There are also other programs out there that lock it as well.  But if it is an HP laptop your stuck with it.

Give HP a call and see if you get somewhere.  I could have just ended up with someone who didnt care enough to help me.

In my case someone has locked the 'C:\$Volume' hidden file in an odd way.  Still havent worked that one out...
Logged
verdy_p
JkDefrag Hero
*****
Posts: 62


View Profile
« Reply #5 on: September 01, 2009, 07:17:22 am »

There are also versions of Sysindexer, and Microsoft Messenger that lock this file.  There are also other programs out there that lock it as well.  But if it is an HP laptop your stuck with it.

Every program running in Windows which currently has some files kept open for writing onto a NTFS volume maintains a lock on the USN journal of that volume, exactly for the purpose of maintaining the integrity of these files and of their allocation on disk, even after a system crash or sudden loss of power (the file will be recoverable safely at reboot, thanks to the transacted actions written in the USN journal which can be replayed for completing an unterminated commit-on-close, or rolled back to the last committed state, in a consistant way).

You could then add also the Windows Update client service (for one of its log files): stop it, and the giant log file it creates will be unlocked (you'll be able to edit and truncate/delete it if you wish), as well as its associated lock on the USN journal.
 
They lock the thing down with something.  I could never get them to tell me what they did to the OS that would cause this.  I have so far seen at least 8 different HP laptops that have this issue.  None of the desktops do.  Doesn't matter if it is 64bit or 32bit.  It seems every other manufacture this works on *except* HP vista laptops.
I am currently writing here using a personal HP Pavilion notebook (a dv7 model, with Intel Core2 Duo processor and 4GB of RAM), running Vista Home Premium 32bit, OEM version preinstalled by HP, that really does not have this issue (the same is true for my work PC, also an HP Pavilion notebook, a bit different and less powerful, but running Vista Pro, 64bit OEM...)

I have perfectly been able to use "fsutil usn deletejournal /n c:" or "fsutil usn deletejournal /d c:"
And also before doing that, "fsutil usn createjournal m=... a=..." to delete and recreate the journal with other (max size, delta alloc) sizing parameters. (And I absolutely don't need to boot in Failsafe mode to logon with the true "Administrator" account, I can do that from the normal personnal account created within the Administrators group when the Windows preinstallation was finished with my personal settings)

I really think that you are not using the administrator account with elevated privileges: if you are using Vista with LUAC enabled, you SHOULD see the LUAC confirmation prompt for administrator elevation when starting the command prompt, before the command windows even appears, before trying these commands. As long as you won't see this LUAC prompt, you can be sure that you are not using the correct Administrator account.

Note: "fsutil usn deletejournal [/n|/d] c:" does NOT really delete the USN journal (the name of the command is misleading), it just recreates it with the minimum value for the max size parameter (4 MiB) and the minimum value for the allocation delta (1 MiB), after transfering the last uncommited transactions from the previous journal to the first created delta for the newly reallocated journal. There is ALWAYS an active USN journal on ALL mounted NTFS volume (NTFS cannot work reliably without it), and it will never be empty.

In other words, it is just a short form of the "fsutil usn createjournal m=... a=... c:" command (which also does not create the journal, but just recreates it with your new sizing parameters)

Final note: I don't use, and in fact I have completely uninstalled immediately the Norton Security Suite trialware that HP installed on these notebooks. I have never wanted it and never used it. I have better antivirus protections than this known bulky/bogous/ressourcehog/costly Norton suite, if this is the cause of your problem, and it has modified the Administrator privileges or blocked some admin features (if you want to keep it, make sure to look at its advanced settings options, if there's a way to reduce its level of "protection" and it currently prohibits you to get the elevated administrator privileges from a command prompt...)

Note that without getting these elevated privileges, you won't also be able to create a working task in the Task Scheduler, in order to run MyDefrag with the local builtin SYSTEM user account (you cannot do that from the Task Scheduler GUI, but it is possible by importing an XML task file: export the created task to an XML file, change the user to SYSTEM with a text editor, then reimport your modified task: running MyDefrag as a scheduled task under SYSTEM can defragment some other files that even the Administrator with elevated privileges cannot open, such as, sometimes, some Windows Update log...)
« Last Edit: September 01, 2009, 08:18:54 am by verdy_p » Logged
jonib
JkDefrag Hero
*****
Posts: 810


View Profile
« Reply #6 on: September 01, 2009, 10:00:29 am »

verdy_p it looks like you're talking about two different NTFS journals.

\$LogFile: That is the internal journal for the NTFS file system, that is always present on the volume and is used for recovery/repair of the file system, you can change the size of the journal with chkdsk /l:size.

\$Extend\$UsrJrnl: This is the USN journal (Change journal) that is used by programs/services to keep track of file/directory changes, and is not critical for the file system, and this can be deleted with "fsutil usn deletejournal", it can take a while before it disappears and some programs can activate it very fast, so it might seem like it wasn't deleted.

More info here (pdf)

And what does LUAC (Lua compiler) have to do with anything Grin I guess you mean UAC.

jonib
Logged

lh
JkDefrag Hero
*****
Posts: 83


View Profile
« Reply #7 on: September 02, 2009, 10:27:26 pm »

@verdy_p
Quote
Every program running in Windows which currently has some files kept open for writing onto a NTFS volume maintains a lock on the USN journal of that volume, exactly for the purpose of maintaining the integrity of these files and of their allocation on disk, even after a system crash or sudden loss of power (the file will be recoverable safely at reboot, thanks to the transacted actions written in the USN journal which can be replayed for completing an unterminated commit-on-close, or rolled back to the last committed state, in a consistant way)

That is the wrong journal.  The journal we are talking about is the USN journal.  It only tracks metadata file changes such as file created, timestamp changed, permissions changed.  It does not track the actual change itself, just that it changed, etc.  It is used by sysindexer, and a few other programs, to know which files to go back and reindex.  It is pretty cool.  For example a virus program may subscribe to this to know 'hey someone messed with this file let me rescan it'.  Or a defragmenter could use it to say 'hey new file or someone messed with a file let me make sure it is defragmented and in the right spot on the disk'.  See the difference?  It is pretty cool.  You are thinking of the recovery logfile which does some recovery things (and usually a pretty bad job at it).

http://smallvoid.com/article/winnt-ntfs-recovery-log.html

Quote
I really think that you are not using the administrator account with elevated privileges
I am getting the prompt even have a special cmd prompt lnk file that is set to log in as admin and get the prompt every time I click it.  Also I have disabled UAC and have logged in with the 'real' admin the hidden one.  Logged in from recovery consoles etc...

I used a sysinternals util and fsutil blows out on the CreateFile when it opens C:\$Volume.  Some other process has it open with access denied to other programs.  I think it has the 'file' open with a read only flag.  I created my own utility that opens C:\ instead of $Volume.  It is able to delete the file and it comes right back.

From the MS documents. 
Change journals are not necessarily created at startup. To create a change journal, an administrator may do so explicitly or start another service that requires a change journal.
Quote
Note: "fsutil usn deletejournal [/n|/d] c:" does NOT really delete the USN journal (the name of the command is misleading), it just recreates it with the minimum value for the max size parameter (4 MiB) and the minimum value for the allocation delta (1 MiB)

I can see you are having a similar issue to what I am.  It deletes the journal (you can actually see the file be deleted if you watch it correctly).  HP has SOME process that is recreating this file.  If you have sysindexer on it could be that as this program uses it.  It would then recreate it instantly, I have seen it do this.  When deleted if you do 'fsutil usn queryjournal c:' you will get an error back saying it is not active.  You will then not find that file on the drive anymore.

On an XP box I use here is what you should see
C:\Documents and Settings\Admin>fsutil usn queryjournal c:
Usn Journal ID   : 0x01c95956557b81f8
First Usn        : 0x00000000eec00000
Next Usn         : 0x00000000f53d0dc8
Lowest Valid Usn : 0x0000000000000000
Max Usn          : 0x00000fffffff0000
Maximum Size     : 0x0000000006400000
Allocation Delta : 0x0000000000400000

C:\Documents and Settings\Admin>fsutil usn deletejournal /N C:

C:\Documents and Settings\Admin>fsutil usn queryjournal c:
Error:  The volume change journal is not active.


I did the same as you with uninstalling Norton.  In the other thread we were speculating that Norton had left something behind.  However did you uninstall all of the HP utilities or just a subset?

Seeing that you are using a DV7 (which is a fairly recent laptop design).  It sounds like they may have corrected the issue in some builds?  The G60t I bought 4 weeks ago with the OEM 64 bit vista home premium on it has the same issue.  I think the G60t is just a respin of an older design.  So I take back my implication that all HP laptops have this issue.  But I have only seen it on them.

In one of my experiments with this I used an MSDN build in a virtual machine.  I was able to see that the file was totally gone.  It did not exist on the disk.  It is not 'always' there.  It only exists if some program subscribes to it.

If you want to see how it works you can read the SDK on the issue
How to use the journal and what it does from the SDK.
http://msdn.microsoft.com/en-us/library/aa363877%28VS.85%29.aspx
How to delete the file using the SDK.
http://msdn.microsoft.com/en-us/library/aa363928%28VS.85%29.aspx

Quote
In other words, it is just a short form of the "fsutil usn createjournal m=... a=... c:" command (which also does not create the journal, but just recreates it with your new sizing parameters)
I can give this a try again tonight when I get home.  However, if I remember correctly (its been months since I messed with this) it was failing for the same reason deletejournal was failing 'access denied'.  I would have to recreate the sysinternals procmon logs to show this.
Logged
bengtang
Newbie
*
Posts: 2


View Profile
« Reply #8 on: December 10, 2009, 01:27:01 am »

I tried the DeleteJournal() script command in the latest MyDefrag version and it worked!! And i did that on a HP laptop running Windows Vista!!!

To do this open the MyDrfrag script file in notepad, and under where it says VolumeActions, put a line saying
DeleteJournal()

Then run the script! I put it in the Defrag free space script.
Logged
lh
JkDefrag Hero
*****
Posts: 83


View Profile
« Reply #9 on: December 11, 2009, 08:07:21 pm »

I should have come back to this as well.  I havent tried the script way (glad it works!).  However, I reinstalled vista and now it works.

However I did not use the restore partition and used a set of restore disks from HP and a new HD.  My old HD which is still in my laptop, still has the issue.  But on the new one I can use the fsutil command.  This also clearly eliminates that I am logged in as the wrong users and not an admin.  As I can fsutil my C drive and not my D drive...

So that puts the issue squarely in the 'its a permisions' issue thing.  I fiddled around with the permisions on the 'broken' drive to see if I could come up with something...  As I do not mind if I hose this drive down now Smiley.  No go so far.

I think the $Volume file has the wrong permissions on it.  However I was unable to look at it.  I have given up for now though.  As with my new HD its is not too big of a deal.  I have use the restore partition on another laptop that was doing the same thing.  After that restore it would not let me delete it.  So I think I got lucky with this restore disk set.

Also keep in mind that doing this will cause the SysIndexer to reindex the whole drive.  So I would put this in a monthly script.  I have been keeping it as a 'separate' thing so SysIndexer can calm down then I defrag the whole drive.  I have had a few occasions where it gets in the way of a 'big defrag' and leaves little gaps in zones.  Which is not that big of a deal as the daily script will clean it up.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!