Re: A FAQ regarding defrag and permissions of nonadmin files?

[Brian Dessent <brian at dessent dot net>]

Gmane User wrote:

> I'm defragging the whole disk, so I need the defragger to be able to
> access all files from whatever account it runs under.

I've never had any problem doing that without having to specifically
loosen any ACLs.

> About defragging as a service, http://support.microsoft.com/kb/120929
> says that the System account has no more permissions than an admin
> account.

I use O&O Defrag, it runs as a service as NT AUTHORITY\SYSTEM, and it
defrags all my Cygwin files just fine without needing to set any special
permissions.  It has been the same way with every other defrag program
I've used too.

> About defragging on boot-up, JkDefrag does this too, but still needs
> an account to run under.  Is it possible for a defrag (or a process)
> to run not under any account?  That is, does Ultra Defragmenter
> actually do this?  Ultra Defragmenter would have been my first choice,
> except that I ran into this caveat:

At the point where UltraDefrag runs only the kernel and drivers have
loaded, the Win32 subsystem and the SAM do not even exist yet -- this is
the whole point of doing it that early in the process, so that things
like the registry hives are not yet open and locked.  So I think this
runs in the absence of any user context.  And even when doing a normal
defrag, UltraDefrag does the actual processing in kernel mode as a
driver and at that level there are no access restrictions whatsoever.  

> http://groups.google.ca/group/alt.comp.freeware/browse_frm/thread/377f0ea5602cc584/855cc4e01f835029.
> I described in my original post the barriers to ghosting in my
> obsolete system, so I'm reticent to experiment with developmental
> defraggers until they built up a bit of a track record.  This decision
> has more to do with safety than how well the algorithm may be coded
> up.

Keep in mind that all of these things are using the same code for the
heavy lifting of actual defragmentation.  That is implemented in the
NTFS.SYS filesystem kernel driver; none of the tools actually touch the
raw disk, they just send an IOCTL to the filesystem telling it to move a
file extent from A to B.  The only thing that differs is the high level
algorithm that decides what goes where, but none of them do the actual
moving.  The risk of data loss therefore is more or less constant and
does not depend on which tool is being used, as I see it.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/