在对视频数据ucf-101进行预处理时，会使用os.mkdir()函数，但是出现了如下错误： 于是单独测试该函数，还是出错： 我的目录结构，目录只手动新建到ucf101 这篇博文介绍了os.mkdir()的详细使用，提到了os.mkdir()不能新建多级文件夹。解决办法也即将换成os.makedirs()函数，就可以新建多级目录。https://blog.csdn.net/ziyuzhao123/...
MAC-python创建目录
通过python 1.在mac的系统用户文档目录下创建目录 如： import os os.mkdir(‘test012’) 2.1在指定目录下创建目录 如： path= ‘/Volumes/MAC1/test001/’ os.mkdir(path + ‘zhu’) 注意最后一级目录的“/”要 写上
【python】几行代码生成日期文件夹
import os year=2020 for month in range(1,13): filename='{}.{}'.format(year,month) os.mkdir(filename) print(filename+'file created.')
python中os模块的常用方法
os.listdir([path]) # 获取path下的所有文件及文件夹 os.mkdir(path) # 在对应的路径下创建文件夹，注意：只能创建一级 os.makedirs(path) # 在对应的路径下创建文件夹...1、os模块是什么： python中os模块包含普遍的操作系统功能，可以处理文件和目录，是Python系统和操作系统进行交互的一个接口。 2、os模块的常用方法： os
python中os模块的用法
文件夹中没有C文件的前提下，想同步创建C文件与该文件下的D文件，报错 os.makedirs(‘fileurl’) #创建多级文件目录 这里就类似与多次使用os.mkdir...;这个目录必须解析符号’)
可以为所有可查找文件的目录 查看桌面中的py文件夹，下有两个文件 查看桌面 如文件目录不正确，则会报错 os.chdir(‘fileUrl&rsquo
Python创建目录文件夹并对数据进行读写操作
参考文件夹操作命令总结：https://blog.csdn.net/qq_33472765/article/details/80841142
Python对文件的操作还算是方便的，只需要包含os模块...D盘的qttc目录下，然而我D盘下没有qttc父目录，如果使用os.mkdir(path)函数就会提示我目标路径不存在，但使用os.makedirs(path)会自动帮我创建父目录qttc，请在
Albert-Jan Roskamunread, Jun 25, 2015, 1:55:50 AM6/25/15 to Hi, Consider the following calls, where very_long_path is more than 256 bytes:
[1] os.mkdir(very_long_path)
[2] os.getsize(very_long_path)
[3] shutil.rmtree(very_long_path) I am using Python 2.7 and [1]
and [2] fail under Windows XP [3] fails
under Win7 (not sure about XP). This is even when I use the "special"
notations \\?\c:\dir\file or \\?\UNC\server\share\file, e.g.
os.path.getsize("\\\\?\\" + "c:\\dir\\file")
(Oddly, os.path.getsize(os.path.join("\\\\?", "c:\\dir\\file")) will
truncate the prefix) My questions:
1. How can I get the file size of very long paths under XP?
2. Is this a bug in Python? I would prefer if Python dealt with the gory
details
of Windows' silly behavior. Regards,
Albert-Jan ---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus Albert-Jan Roskamunread, Jun 25, 2015, 4:06:01
PM6/25/15 to Hi, Consider the following calls, where very_long_path is more than 256 bytes:
[1] os.mkdir(very_long_path)
[2] os.getsize(very_long_path)
[3] shutil.rmtree(very_long_path) I am using Python 2.7 and [1] and [2] fail under Windows XP [3] fails under Win7 (not sure about XP). It throws: “WindowsError:
[Error 206] The
filename or extension is too long” This is even when I use the "special" Steven D'Apranounread, Jun 25, 2015, 5:16:47 PM6/25/15 to On Thursday 25 June 2015 18:00, Albert-Jan Roskam wrote: > Hi,
>
> Consider the following calls, where very_long_path is more than 256 bytes:
> [1]
os.mkdir(very_long_path)
> [2] os.getsize(very_long_path)
> [3] shutil.rmtree(very_long_path)
>
> I am using Python 2.7 and [1] and [2] fail under Windows XP [3] fails
> under Win7 (not sure about XP). It throws: “WindowsError: [Error 206] The
> filename or extension is too long” I don't think this is a bug. It seems to be a limitation of Windows.
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath > This is even when I use the "special"
> notations \\?\c:\dir\file or \\?\UNC\server\share\file, e.g.
> os.path.getsize("\\\\?\\" +
"c:\\dir\\file") However, that may be a bug. What happens if you use a Unicode string? path = u"\\\\?\\c:a\\very\\long\\path"
os.mkdir(path) Can you open an existing file? open(u"\\\\?\\c:a\\very\\long\\path\\file.txt") > (Oddly, os.path.getsize(os.path.join("\\\\?", "c:\\dir\\file")) will
> truncate the prefix) That's worth reporting as a bug. > My questions:
> 1. How can I get the file
size of very long paths under XP? If all else fails: last = os.getcwd()
try:
os.chdir('C:/a/very/long')
os.chdir('path/with/many')
os.chdir('nested/folders')
os.path.getsize('/and/even/more/file.txt')
finally:
os.chdir(last) > 2. Is this a bug in Python? I would prefer if Python dealt with the gory
> details of Windows' silly behavior. I would say that it is a bug that it doesn't work with extended-length
paths
(those starting with \\?\) but may or may not be a bug with regular paths. --
Steve Chris Angelicounread, Jun 25, 2015, 5:23:38 PM6/25/15 to On Thu, Jun 25, 2015 at 7:16 PM, Steven D'Aprano
<steve+>
wrote:
>> 2. Is this a bug in Python? I would prefer if Python dealt with the gory
>> details of Windows' silly behavior.
>
> I would say that it is a bug that it doesn't work with extended-length paths
> (those starting with \\?\) but may or may not be a bug with regular paths. I'd go further and say that the OP is right in expecting Python to
deal with the gory details. Would it break anything for Python to
prepend \\?\ to all file
names before giving them to certain APIs?
Then the current behaviour of stripping off that prefix would be fine. Are there any times when you *don't* want Windows to use the
extended-length path? ChrisA Tim Goldenunread, Jun 25, 2015, 6:10:30 PM6/25/15 to On 25/06/2015 10:23, Chris Angelico wrote:
>
On Thu, Jun 25, 2015 at 7:16 PM, Steven D'Aprano
> <steve+> wrote:
>>> 2. Is this a bug in Python? I would prefer if Python dealt with the gory
>>> details of Windows' silly behavior.
>>
>> I would say that it is a bug that it doesn't work with extended-length paths
>> (those starting with \\?\) but may or may not be a bug with regular paths.
>
> I'd go further and say that the OP is right in expecting Python to
> deal with the gory details. Would it break anything for Python to
> prepend \\?\ to all file names before giving them to certain APIs?
> Then the current behaviour of stripping off that prefix would be fine.
>
> Are there any times when you *don't* want Windows to use the
> extended-length path? Yes: when you're passing a relative filepath.
Which could pretty much be
any time. As you might imagine, this has come up before -- there's an
issue on the tracker for it somewhere. I just don't think it's simple
enough for Python to know when and when not to use the extended path
syntax without danger of breaking something. Bear in mind that the \\?\ prefix doesn't just extend the length: it
also allows otherwise special-cased characters such as "." or "..". It's
a general-purpose mechanism for handing
something straight to the file
system without parsing it first. TJG Chris Angelicounread, Jun 25, 2015, 6:24:18 PM6/25/15 to On Thu, Jun 25, 2015 at 8:10 PM, Tim Golden <> wrote:
>> Are there any times when you *don't* want Windows
to use the
>> extended-length path?
>
> Yes: when you're passing a relative filepath. Which could pretty much be
> any time. As you might imagine, this has come up before -- there's an
> issue on the tracker for it somewhere. I just don't think it's simple
> enough for Python to know when and when not to use the extended path
> syntax without danger of breaking something. Oh blah. So I suppose that means there's fundamentally no
way to use a
long (>256 byte) relative path on Windows? > Bear in mind that the \\?\ prefix doesn't just extend the length: it
> also allows otherwise special-cased characters such as "." or "..". It's
> a general-purpose mechanism for handing something straight to the file
> system without parsing it first. Ohh. So... hmm. So what this really means is that a path could get
\\?\ prepended when, and ONLY when, it becomes absolute.
Windows can
be a real pest... ChrisA
Mark Lawrenceunread, Jun 25, 2015, 7:07:06 PM6/25/15 to On 25/06/2015 09:00, Albert-Jan Roskam wrote:
> Hi,
>
> Consider the following calls, where very_long_path is more than 256 bytes:
> [1] os.mkdir(very_long_path)
> [2] os.getsize(very_long_path)
> [3] shutil.rmtree(very_long_path)
>
> I am using Python 2.7 and [1] and [2] fail under Windows XP [3] fails
> under Win7 (not sure about XP). It throws: “WindowsError: [Error 206] The
> filename or extension is too long” This is even when I use the "special" > notations \\?\c:\dir\file or \\?\UNC\server\share\file, e.g.
> os.path.getsize("\\\\?\\" + "c:\\dir\\file")
> (Oddly, os.path.getsize(os.path.join("\\\\?",
"c:\\dir\\file")) will
> truncate the prefix)
>
> My questions:
> 1. How can I get the file size of very long paths under XP? Please see
https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath > 2. Is this a bug in Python? I would
prefer if Python dealt with the gory
> details of Windows' silly behavior. I don't see why Python should work around any particular limitation of
any given OS. --
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language. Mark Lawrence Joonas Liikunread, Jun 25, 2015, 8:05:04 PM6/25/15 to Python It sounds to me more like it is possible to use long file names on windows
but it is a pain and in python, on windows it is basically impossible. So shouldn't it be possible to maniulate these files with extended names.. I mean even if you had to use some special function to ask for long names
it would still be better than no support at all. Tim Goldenunread, Jun 25, 2015, 8:35:06 PM6/25/15
to Python On 25/06/2015 13:04, Joonas Liik wrote:
> It sounds to me more like it is possible to use long file names on windows
> but it is a pain and in python, on windows it is basically impossible. Certainly not impossible: you could write your own wrapper function: def extended_path(p):
return r"\\?\%s" % os.path.abspath(p) where you knew that
there was a possibility of long paths and that an
absolute path would work. TJG Message has been deleted Chris Angelicounread, Jun 25, 2015, 9:02:46 PM6/25/15 to On Thu, Jun 25, 2015 at 9:06 PM, Mark Lawrence <> wrote:
>>
2. Is this a bug in Python? I would prefer if Python dealt with the gory
>> details of Windows' silly behavior.
>
>
> I don't see why Python should work around any particular limitation of any
> given OS. Check out the multiprocessing module, and then tell me whether it's
better that Python paper over the OS differences or if you'd rather do
all that yourself. The biggest difference left between Windows and
POSIX is that on Windows,
your main module has to be importable (which
doesn't hurt on POSIX). Python deals with all the mess of "can we
fork, or do we have to do it differently?". ChrisA Michael Torrieunread, Jun 25, 2015, 9:36:01 PM6/25/15 to The OP mentions that even when he manually supplies extended paths,
os.mkdir, os.getsize,
and shutil.rmtree return errors for him in Python
2.7. So there's more to this problem.
Tim Goldenunread, Jun 25, 2015, 9:38:09 PM6/25/15 to He's probably not passing unicode strings: the extended path only works
for unicode string. For 3.x that's what you do by default. TJG Terry Reedyunread,
Jun 26, 2015, 1:05:31 AM6/26/15 to If possible, please try the same operations with Python 3.4 or .5 before
making a report --
Terry Jan Reedy unread, Jun 26, 2015, 1:54:14 AM6/26/15 to On Thu, Jun 25, 2015, at 09:35, Michael Torrie wrote:
> The OP mentions that even when he manually supplies extended paths,
> os.mkdir, os.getsize, and shutil.rmtree return errors for him in Python
> 2.7. So there's more to this problem. The byte versions of the underlying OS APIs use a 256-character buffer
to do conversion - he needs to also be passing unicode strings.
Albert-Jan Roskamunread,
Jun 27, 2015, 1:49:14 AM6/27/15 to On Thu, 25 Jun 2015 14:37:55 +0100, Tim Golden wrote: > On 25/06/2015 14:35, Michael Torrie wrote:
>> On 06/25/2015 06:34 AM, Tim Golden wrote:
>>> On 25/06/2015 13:04, Joonas Liik wrote:
>>>> It sounds to me more like it is possible to use long file
names on
>>>> windows but it is a pain and in python, on windows it is basically
>>>> impossible.
>>>
>>> Certainly not impossible: you could write your own wrapper function:
>>>
>>> def extended_path(p):
>>> return r"\\?\%s" % os.path.abspath(p)
>>>
>>> where you knew that there was a possibility of long paths and that an
>>> absolute path would work.
>>
>> The OP mentions that even when he manually supplies extended paths,
>> os.mkdir, os.getsize, and shutil.rmtree return errors for him in Python
>> 2.7. So there's more to this problem.
>>
>>
> He's probably not passing unicode strings: the extended path only works
> for unicode string. For 3.x that's what you do by default. Hi all, Thanks for your replies. I've been messing with this a bit
more. I
created a little test script (see below). However, this only works with
drive letters, not with UNC paths. I tried using os.chdir, DOS pushd,
subst, net use but they all don't seem to work with with looooong paths.
I finally managed to remove an absurdly long dir with shutil.rmtree,
after changing sys.setrecursionlimit. But my main goal was to get the
file size (and, actually, also the file owner) of a long file name on XP. import os
import shutil
import sys # create an insanely long directory tree
p = os.getenv("TEMP")
#p = ur"\\server\share\blah\temp"
tmpdir = p
os.chdir(tmpdir)
for i in xrange(1000):
tmpdir = os.path.join(tmpdir, "sub")
os.mkdir("\\\\?\\" + tmpdir)
#os.mkdir(u"\\\\?\\UNC" + tmpdir[1:]) # write a file to it
deep = "\\\\?\\" + os.path.join(tmpdir, "deep.txt")
assert os.path.exists(deep)
with open(deep, "w") as f:
f.write("Deep!\r\n") # try if
the file size can be determined (requires special \\?\ notation)
print "@@@@ %d bytes" % os.path.getsize(deep) # now delete the whole directory and its contents.
path = "\\\\?\\" + os.path.join(p, "sub")
path = path.decode(sys.getfilesystemencoding())
sys.setrecursionlimit(10 ** 7) # net use, pushd, subst will not work
shutil.rmtree(path) Any feedback is welcome. I will post the solution somewhere so somebody
else will be spared this nuisance. :-)
Albert-Jan Roskam
unread, Jun 27, 2015, 2:00:03 AM6/27/15 to <snip> > import os import shutil import sys
>
> # create an insanely long directory tree p = os.getenv("TEMP")
> #p = ur"\\server\share\blah\temp"
> tmpdir = p os.chdir(tmpdir)
> for i in xrange(1000):
> tmpdir =
os.path.join(tmpdir, "sub") os.mkdir("\\\\?\\" + tmpdir)
> #os.mkdir(u"\\\\?\\UNC" + tmpdir[1:])
>
> # write a file to it deep = "\\\\?\\" + os.path.join(tmpdir, "deep.txt")
> assert os.path.exists(deep) sorry, this "assert" should of course follow 'with open(..' Tobiahunread, Jul 7, 2015, 11:56:21 PM7/7/15 to On 06/24/2015
10:45 AM, Albert-Jan Roskam wrote:
> Hi,
>
> Consider the following calls, where very_long_path is more than 256 bytes:
> [1] os.mkdir(very_long_path)
> [2] os.getsize(very_long_path)
> [3] shutil.rmtree(very_long_path)
>
> I am using Python 2.7 and [1] and [2] fail under Windows XP [3] fails
the prefix)
>
> My questions:
> 1. How can I get the file size of very long paths under XP? As a
workaround, could you use multiple calls to os.chdir()
to get to where you need to do your operations, then use
relative paths from there? Tobiah | 
